I love Lighthouse. Since I was introduced to it in March last year it has been my favourite web app. Up until that point I'd been using a set of Omni Outliner documents. Now these worked quite well for a while, but I soon began to outgrow them and started looking at dedicated issue trackers.

I looked at the usual suspects: Trac, FogBugz, Mantis, Jira etc. None of them really clicked with me, they seemed to do too much or have overly complicated UIs. Lighthouse was different, it was designed to be simple. It didn't try to be everything to everyone like some of the above. It let you file tickets, assign them to someone and then work your way through them. And most of all, it had an incredibly well designed UI.

Of course, I'm not exactly the biggest fan of web apps. They're fine to use occasionally, but when it's something you're working with all day it's frustrating to either have to keep logging in, or at least keep a Safari window open. Luckily the Lighthouse developers provided a pretty comprehensive API so I thought that I'd set about making a desktop client to get around this.

That was in March 2007. In July 2008 I'm finally able to declare that M Cubed's 3rd application is now in beta testing. Say hello to Lighthouse Keeper:

Lighthouse Keeper's main window

The road has been long and extremely rocky. I've completely scrapped and started over 3 times and then completely took the app in an entirely different direction requiring a massive re-write. In fact, just over 2 months ago I was ready to give up on Lighthouse Keeper until after the Summer when my latest attempt failed.

So why has it been so hard? Well simply, there was no really clear metaphor for a ticket in my head. I had an initial idea of just allowing you to search, view and add tickets. Most of the iterations revolved around that. I also had a bad case of trying to generalise things too early on. I was trying to build a framework and then make an application using that, rather than the other way around.

My mind got stuck in this idea that all I needed to do was have a small menu bar app that let you search and add tickets. The problem is that the resulting application kept getting too complicated. Then on my 3rd re-write I decided to do a lot more, to offer more way to search and view data and to handle ticket bins and milestones. Things started to come together, but they were still incredibly complicated.

Lighthouse Keeper circa April 2008

It's amazing how easy it is to get stuck into believing something is right if you work at it for long enough. I actually spent several months believing that the above screenshot represented the best UI for Lighthouse Keeper. Then I took a few weeks off to work on some other projects and when I came back I saw the project with new eyes. It was awful.

Luckily I finally came up with a viable metaphor for tickets: email. If you think of a ticket as an email then you start to view the app as an email client of sorts. So with a sharp turn of the development steering wheel I did a U turn and started to re-design the UI. The one bit of good design to come out of the previous iteration was the code that talked to the Lighthouse API. It was very solid and self contained enough for me to completely rebuild the UI while always having a semi working application.

It is a testament to the power of Cocoa that I was able to completely change how my application functions and re-write it in just 2 months. The resulting UI is one I can safely say is the best for the job. It works, is easy to learn, is consistent and most of all, it makes sense for what you are doing.

Over the next few weeks I'll be introducing you to Lighthouse Keeper bit by bit in the build up to 1.0. Never has issue tracking been so easy and hassle free.

(6) Comments