TCRM and the Comprehensive Design

Well yesterday was my first day at TCRM, a web design company based in Bridgend, South Wales. I’ve officially joined Kevin and Andrea as part of the team in the office extension of Kevin’s house. It’s not as rustic as you might think. There are those big processed wood desks you get in every office in Britain, a nice two-monitor Windows 7 systems for each of us, and those little spot light things in the ceiling. We have music playing over decent quality speakers and as much coffee as we can drink in order to slip into a caffeine-induced coma. There is the occasional disagreement about what music will play and the best way to take your coffee, but all in all it’s a pretty sweet set up.

One of my tasks was to design the data structure for a site which includes a section where people can define their funeral wishes online (stick with me here). Anyway, the specification states that there are two fields, music and flowers, which were intended to be a catch all for these requirements. My first thought was to stick with the spec and code it up, making them big text fields and allowing the user free reign as to what was defined. I was just working my way down the list of fields at this point, but Kevin recited one of the commandments of application design to me (and this is why it’s good to do initial design work collaboratively) that you should never trust user input. No booming voice, thunder claps or bushy beard but the idea is sound. He envisaged a site that would prompt for every piece of information. If they wanted a piece of music, there would be a field for composer, a field for performer etc. Nothing would be left to chance.

Between us we also came up with the idea of building up an itinerary so you can build up your funeral event by event. A reading can follow a piece of music, which can be followed by a hymn and so on. But that would mean that in order to control user input each kind of event would need it’s own set of parameters and if you added an event in the future new parameters would have to be added. Try coding that up. You need a separate table for each event type and a separate interface for each. Yes I’ve seen examples of people overcoming this by prying multiple data structures into a single table with ‘FieldName’, ‘DataType’ fields, but I think that’s very bad technique as it breaks the relational database model. So a middle ground was struck. The funeral would be built up event by event, with the user being guided to choose what sort of event it was (such as a reading or piece of music) and prompted with a 256 character text field to give further details. Everyone is happy.

It is important in all applications to design an application which guides the user as smoothly as possible through the process, yet still allowing the data structure to be flexible and coded up efficiently. It’s not an easy balancing act, but you can get there!