My Customer

My "customer" for this project is a non-profit who really, really needs a new database application.  Their current application is a single-user custom database built in PowerBuilder.  What's more, the developer of this application had no real idea about usability and interface design.

I can't really single him out for blame though, without also "blaming" the customer for not really being able to articulate in technical terms what they wanted when they were first working to build this application.  It's not their fault for not being able to speak to technology, any more than it isn't this developer's fault for not having the benefit of the intervening 15 years of interface design.

So, I get the benefit of standing on a whole bunch of people's shoulders to build what I would expect is going to be a very basic interface to a very basic contact database.  It's very easy to throw stones, but quite another thing entirely to build a glass house.

I could probably cheat this by falling back to technologies with which I am familiar: I am sure, for example, I could knock out this application in a couple of days using Oracle APEX.  I know Oracle databases like the back of my hand, and while APEX gives a very crude-looking result that's all the more I am after.

However, I want to learn a new language and framework, and being well-impressed with what I see in Scala I'm going to give it a lash. While I've done some functional programming in the past I am far more familiar with the imperative style.  So, apologies in advance to those who might be looking to this as a source of "how do I get started programming in Scala/Lift".  I am unlikely, at first attempt, to devise some brilliant coding patterns.

So, where to begin.  I'll start with a summary of my observations after spending much of last Monday in their offices reviewing their IT systems as a whole.  This, their sole contact database, came up repeatedly. As I asked how they do various things involving the database, it became quite clear that the application is very difficult to use.

For example, to generate a mail shot there are about 40 different clicks involving three different applications (this database, Excel, and Word).  To log a call, there are 15 different clicks involved, including logging in and out of the database.

This last point is probably the biggest value add: only one user can be logged into the database at a time.  This means that only one person can log a call, or query the database, or do anything in the database at once.  There's not that many staff (maybe a dozen) but when the majority of your staff are interacting with customers and trying to log those interactions into the database ... well ... the database becomes a problem.

So, there is my first story:

• As a user, I want to be able to use the database at the same time as other users.

Of course, I don't even have an application, let alone a database or users.  So...I'll break this story down into the following tasks:

1. Create a login page
2. Create a "add user" request function
3. Allow users to edit their details, including password, and log in/out of the system

The acceptance of this story will be:

1. Log into the application as "user 1"
2. On a different machine, log into the application as "user 2"
3. "User 1" should still be logged into the application

The completion of this story will, of course, expose a whole new problem...namely that there is no application (or "database" as they call it) to provide any real function.  But, we'll have solved the biggest pain point: multiple users will be able to log into the application simultaneously.