Building A Web-App 101

As promised, this is the first part of a short series of posts on building the new invoicing system for Griffin Multimedia.

First off, a little bit of background - the raison d'etre if you will. Prior to building this system, we've handled invoicing tasks by writing them up in Word or OpenOffice, PDF-ing them, and sending them off to clients. Now that's been fine for a fair while, but now that we are getting busier, with recurring charges for subscriptions and whatnot it has gradually become unmanageable. There being three of us issuing invoices doesn't help much either!

I've been jotting down notes, sketches and schema diagrams for a solution for several months now - procrastinating carefully thinking about how to replace our outgrown procedure with something shiny. Late April I finally decided that the only way to get it going was to build the bloody thing and be done with it. What's that they say about the blank page being the scariest place to start anything?

In the next few posts I hope to look back on the development process of the system under Ruby on Rails, with particular emphasis on what actually went into building it rather than how it's been built (What does this look like, a RoR HOWTO!?!).

Why? Well, I think a lot of people misunderstand what goes into building a web-application (of any complexity), and I also want to give a bit of a rundown on my interpretation of the 37signals-inspired notion of Getting Real and starting development with the user screens (read some of the PDF here)

Part One - Where to Start?

As I have already mentioned, the hardest part of any project is laying something down as a start point. My usual approach is to start bashing out a schema of what's in the system, map all the relationships, work out the object model, and then start plugging stuff into that. Build the code and the GUI will reveal itself sort of thing. A recent large project was built precisely in this way - the bulk of the complexity of the system was behind the scenes, not directly connected to any interface.

There is a school of thought however, championed primarily by the 37signals crowd, of building from the interface first. This notion intrigues me - I'm always open to try a new way of doing something, and it's always much better to do those kinds of things on a personal project rather than with a client, deadlines and all of those nice stressful things.

First step was easy then - grab a pencil and paper and start sketching out how I wanted to interact with the system (as the main user). I worked out what things I would be doing often (adding charges to clients, adding payments, viewing client information) and designed a page structure around that. I know I wanted it to be simple, so I set about making wire-frames with as little clutter as possible.

This led to the next step - mockups. I've recently had a bit of a fling with Inkscape (which is likely to turn into something a bit more if I remember to buy it flowers every now and again) so mockups were fairly quickly knocked up in SVG format. Mmmmm... Vector goodness! (The new version is schmick - have a look if you haven't already).

So why do mockups in this way first? Well, you could fly straight into HTML if you wanted to, but to me that is more difficult - to move something around in a HTML mockup you need to tinker with the source and with CSS positioning (and hope to hell that you don't have to mess with box model hacks, floating and friends). Working with SVG (or Photoshop, Fireworks, or whatever your tool of choice is) means that making these changes are easier, so you're more likely to make the changes to want rather than just saying "oh yeah, it's good enough". Good enough sucks.

screenshot of editing a mockup page in Inkscape

Now, our sturdy vectorific mockups (which perfectly capture how we want it to work rather than settling) in hand, we can set about building real-life HTML mockups of some of the more curly things, especially those requiring AJAX or other dynamic technologies.

In my case, I selected a few important pages from the list that I expected to be using regularly - New Charge, New Payment, etcetera. I mocked into the design as much realistic data as I could - no "lorem ipsum" for us! I also mocked up how I wanted the end product - an Invoice to a client - to look in HTML format.

the version of the previous mockup image constructed in HTML format

In the next post, we'll actually start making our pretty static pages do something web-application-like.