TCRM and the Function Form Debate

Crowded around the TCRM coffee table we ventured whole heartedly into the realm of the old function verses form debate. While what actually started off the discussion is not fit for public consumption, and my view of one of my favourite chocolate egg sweets has been corrupted forever, it did raise the important issue of getting the balance correct between the look and the function of a website.

Unfortunately for us geeks, not everyone is impressed with the purely functional aspects of a website. The new version of the TCRM e-commerce system I have been working on this week now includes some advanced carriage options which delivers a much more flexible system for the seller. Different delivery zones can be defined by the site administrator and a surcharge type can be selected for each product. Still with me? The shopping cart then calculates the carriage for each product based on the standard item cost per item in that delivery zone and adds to that the surcharge for that delivery zone. This complex flexibility results in the grand output of a couple of numbers, a decimal point and a pound sign. You can’t draw people into your site based on how your calculate your carriage.

Yet how many sites can you think of that look stylish but don’t do much at all. The big flash demo you skip over after ten seconds, the brochure web sites with about fifteen words telling you about the company, and remember the blinking text effect from the 1990’s. All bling and no brain websites will hold people’s attention for about 2 seconds if you’re lucky. We look at many of competitors offerings including many Cardiff Web Design companies and notice form over function everywhere, it’s like owning a Rolls Royce with a Trabant engine, not a good thing .

What is needed to a balance between form and function. A site which is functionally rich and looks good doing it. The fact that all TCRM websites now come with a dynamically generated hierarchical site map is lost on most people. (It’s really hard to achieve with some fiddly XML parsing and database cross checking so only the user visible pages are listed) However it’s the funky green font, nice indentation and bullet points which will do it for most people and it’s that which makes it a good page for them. You can view it here if you like and see whether it’s the form or the function which do it for you. Think I’ll still pass on the proposed cream egg though.

TCRM

TCRM and the Rubber Ducky

Internet database applications can be tedious to code sometimes. If you have multiple pages, each administering a different table in your database, then the four basic functions for each- add, edit, delete and list, soon mean you are drowning in field names, passed parameters and cutting & pasting your code all over the place and changing variable names for the 347th time. This is not the cutting edge of the information technology ladies and gentlemen.

After such a day I was left wondering just how far you can go down the road of code generation and why everyone isn’t doing it. Enter the names of the fields and your table names then hit go. Your forms are automatically generated, the tables are scripted and the form submission is all given to you. If you’re very nice it might even add a comment or two. Cut and paste the code in and there you go. Hey you could even write a whole online application with just one field list and a click.

I have ventured down this golden path of code generation before in my previous life as a classic ASP programmer. I had a Microsoft Access database which would generate the form processing code and JavaScript for me from the list of fields I provided manually. It saved me a lot of time and effort and much cutting and pasting between pages. It should be easy to take it a step further and generate the tables and HTML forms for me. We could create ten websites a day, earn our millions in a couple of years then sit back on a beach somewhere with a drink in our hands and water lapping around our ankles.

Well the only water lapping anywhere near me yesterday was the bath water of my eight month old daughter. She was very happy with lots of bubbles, her rubber ducks, the orange octopus and purple penguin (which I’m sure was also a drink). They were cheap to buy, are nice and colourful, keep her entertained and gives her something to chew. The ducks are made in Thailand, while the higher quality octopus and penguin were Chinese in origin. All the best plastic trash is made in China. They probably churn them out by the million and cost pennies to make.

But what if you don’t want the standard rubber duck on offer? What if you want to have it with a bigger tail, or an open beak or with its wings unfolded, or in a very specific colour? Everyone can get rubber ducks, you want to stand out from the crowd and fits your idea of a great duck. Then you’re into the world of custom made rubber ducks. A whole new ball game!

So yes I could go very far down the road of code generation, but then the sites it produces will be very limited, similar and difficult to customise without many hours of additional work. A good site is crafted, it fits the customer’s needs exactly and stands out a little bit from the crowd because it does a specific job well. I will be creating some more tools in the very near future (which I shall go into in a future blog) but until then I can be comforted by the fact that TCRM is crafting web sites that meet the customer’s needs and fulfilling a purpose, and is not churning out 99p websites every five minutes.

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!