Us Bridgend Web Designers are a sturdy bunch, but to label the last few weeks as a little nippy would be something of an understatement. I don’t think I’ve layered up and put on an extra pair of socks as often as this ever. The TCRM office isn’t the warmest of places first thing in the morning normally but I’ve been expecting to find penguins nesting under my desk lately. And not just your run of the mill penguins either. These are hardcore birds who think the arctic is for the wussies.
Anyway, despite the cold it’s been a busy an interesting few weeks here in TCRM, hence the late arrival of this blog entry. Sites have been launched and PCs fixed, quotes delivered and changes implemented. PC repairs are one area that seem to have picked up recently and many of the machines coming in are suffering from virus or malware problems. Adequate virus protection costs nothing but a little time and effort with AVG being the leader in this respect. I’ve been using it for years and haven’t lost any data, been plagued with pop-up windows and rogue services which site there hogging resources and stopping other services from playing with the toys.
Another way of avoiding the problem is exercising a little care over what is being installed on your machine. Remember you don’t have to install every tool bar and little app which comes your way. People won’t point at you in the street and mock you in a mildly hysterical way if you don’t have the Instant Chat 5.0 Cool Smiley Pack installed on your messenger. Plain and simple is the way forward. You’ll be much more productive with a working simple machine and we can help you by putting effort into other areas for you such as web design.
With more cold weather on the way it could signal more ill PCs coming into the office suffering with viruses, but as long as you wrap them up nice and cosy with the latest free virus software and don’t expose them to the chill of unfriendly software, they should be good to see you through the winter.
Monday 13 December 2010
Friday 12 November 2010
TCRM and Life in a Small Business
Us Bridgend web designers are really in the grips of autumn now. The evenings are darker, the skies greyer, the jumpers thicker and the leaves are piling up on the pavements. Those leaves are also being dragged into our office at an alarming rate. It eventually got to a point when enough was enough and Kevin was forced to drag the vacuum cleaner out. So there’s the owner of the company, hoover in hand, cleaning up the leaves on the carpet while Andrea and I looked on (it was a good time for a coffee break). But it got me thinking how different life is in a small company compared to a large organisation. As with everything, there are good points and bad points.
Kevin and I have both worked in very large organisations and after working here for over three months now I can tell you that the differences are huge. Where as before we would pick up the phone and call facilities management department to send a cleaner around to our office, we have to clean ourselves. Though there is something to be said for getting down and dirty. It does keep your feet on the ground.
One of the biggest differences is the importance of our effort. If we all don’t put 100% effort in every day, the business suffers. There is no one else to blame, to fall back on, or to wait on. It’s our responsibility to give the customer the best possible websites and after sales service we can. I always thought I had a pretty good working ethic, but this is something else. Never before have I been in a job where you look at the clock and think of how little time I have left to get things done. It’s working flat out all the time, but at the end of that day I more often than not feel that I have at least done a good day’s work. Though we may have lost some of that comfort zone you experience in a large company, that feeling of doing a making a difference does make up for it.
Kevin and I have both worked in very large organisations and after working here for over three months now I can tell you that the differences are huge. Where as before we would pick up the phone and call facilities management department to send a cleaner around to our office, we have to clean ourselves. Though there is something to be said for getting down and dirty. It does keep your feet on the ground.
One of the biggest differences is the importance of our effort. If we all don’t put 100% effort in every day, the business suffers. There is no one else to blame, to fall back on, or to wait on. It’s our responsibility to give the customer the best possible websites and after sales service we can. I always thought I had a pretty good working ethic, but this is something else. Never before have I been in a job where you look at the clock and think of how little time I have left to get things done. It’s working flat out all the time, but at the end of that day I more often than not feel that I have at least done a good day’s work. Though we may have lost some of that comfort zone you experience in a large company, that feeling of doing a making a difference does make up for it.
Friday 8 October 2010
TCRM and the Moving Goalposts
One of the most fundamental problems that people can have when designing websites, and software in general for that matter, is the lack of a goal. ‘What am I trying to achieve?’ is the question that needs answering the most for it is one of the most influential. It guides the development of the site or software by providing a framework to design choices. You can ask yourself the question, ‘Which option will help me achieve my goal?’ and all of a sudden, choices become clearer.
Writing anything without everyone, including yourself, having a clear understanding of what you are trying to achieve is just asking for trouble. If you are trying to create a slick business site, you’ll want to steer clear of smileys and gimmicks and make it feature rich with good reporting tools. If you’re creating a popular social site, then you’ll want to spend real time and effort on the commenting engine while not worrying too much about every possible field an event can have. When you’re planning your ping pong club’s pub crawl, you don’t need to specify whether the facilities include an overhead projector and the number of available network points. Just the name of the first pub and what time the drinking starts.
Extreme examples of web design problems yes, but it does highlight the approach you need to take. Lack a clear vision and every feature that catches your eye can get thrown into the mix and you’ll find yourself knee deep in features, which all cost time and effort, and in the end you really don’t need. Worse of all though, you’ll be at risk from feature creep.
Without a clear vision at the start your system will grow and develop a life of its own as you try and find your way. As the system reveals itself you’ll gain a better understanding of what you want so feel the need to add more features. This is fine if you’re writing a system or site for yourself in your spare time. But if you’re contracting out the work or working with your IT team to put the system together for you, you’ll soon have a disaster on your hands. Code will be need to be rewritten or thrown out all together, designs trashed, object models broken. Programmers don’t like doing this at the best of times. Having it forced upon them by others is the equivalent of someone telling a builder they have to alter the house they’re halfway through because the buyer wants the kitchen to point south. A lot of blood, sweat and tears went into it and no one wants to see it lost in vain. This tends not to happen so much in the building trade though because everyone can see how much work goes into a house. How many times have you been asked, ‘Can I have a button which does this?’ After all a button is only a small thing isn’t it? Also, builders have really easy access to sledgehammers.
So in order to stop us Bridgend geeks or your fellow geeks coming at you brandishing their pencils which have been sharpened to a very fine point, work out what you want to achieve before you start putting the system together. Much blood, sweat and tears will be saved.
Writing anything without everyone, including yourself, having a clear understanding of what you are trying to achieve is just asking for trouble. If you are trying to create a slick business site, you’ll want to steer clear of smileys and gimmicks and make it feature rich with good reporting tools. If you’re creating a popular social site, then you’ll want to spend real time and effort on the commenting engine while not worrying too much about every possible field an event can have. When you’re planning your ping pong club’s pub crawl, you don’t need to specify whether the facilities include an overhead projector and the number of available network points. Just the name of the first pub and what time the drinking starts.
Extreme examples of web design problems yes, but it does highlight the approach you need to take. Lack a clear vision and every feature that catches your eye can get thrown into the mix and you’ll find yourself knee deep in features, which all cost time and effort, and in the end you really don’t need. Worse of all though, you’ll be at risk from feature creep.
Without a clear vision at the start your system will grow and develop a life of its own as you try and find your way. As the system reveals itself you’ll gain a better understanding of what you want so feel the need to add more features. This is fine if you’re writing a system or site for yourself in your spare time. But if you’re contracting out the work or working with your IT team to put the system together for you, you’ll soon have a disaster on your hands. Code will be need to be rewritten or thrown out all together, designs trashed, object models broken. Programmers don’t like doing this at the best of times. Having it forced upon them by others is the equivalent of someone telling a builder they have to alter the house they’re halfway through because the buyer wants the kitchen to point south. A lot of blood, sweat and tears went into it and no one wants to see it lost in vain. This tends not to happen so much in the building trade though because everyone can see how much work goes into a house. How many times have you been asked, ‘Can I have a button which does this?’ After all a button is only a small thing isn’t it? Also, builders have really easy access to sledgehammers.
So in order to stop us Bridgend geeks or your fellow geeks coming at you brandishing their pencils which have been sharpened to a very fine point, work out what you want to achieve before you start putting the system together. Much blood, sweat and tears will be saved.
Tuesday 21 September 2010
TCRM and Compliant Web Design
Microsoft have just announced that Internet Explorer 9 beta is now available for download. Amongst other things it boasts integrated web search tools, HTML5 compliance and a shiny new slimline interface. That’s right, this means this brand spanking new product is offering what it’s competitors currently do, but the main event though is the collective sigh web developers around the world, and Bridgend Web Designers in particular, are making as they foresee more blood, sweat and tears to make their websites compatible with the software giant’s latest offering.
In the ideal world all browsers will follow the agreed upon standards to the letter and us developers can plan our websites to the standard even before the new browsers are written because they will all act as set out in the standard. In this world cheeseburgers are also free.
Reality is a grim dark world filled with quirks, workarounds and those little CSS bugs which turn a simple menu update into a eight hour slog, by the end of which you question your career choices. I had to deal with one such bug this week. PDF files created on the fly using PHP are a very powerful tool and a useful addition to any website. Even though the file itself is a PHP file, by specifying in the header that the content of the request response is a PDF file, the browser treats it as such. Well this is how it’s supposed to work, and does work like a dream in Firefox. IE doesn’t play by the rules. Rules are for whimps and IE is a big boy with long trousers and everything. IE just looks at the filename in the URL and goes from there. If it sees that the URL ends in .php, it interprets it as a PHP. You can see the problem here. The only working solution for our PDF writer is to create a temporary PDF file and redirect the browser to that. It’s just these little workarounds and fixes which can suck up the effort.
Because of these bugs developers have to react to new browsers coming out instead of planning for their release. Developers have to wait until they get their grubby little hands on the browsers before they can write websites for them as we need to see what quirks and how closely the standards have been adhered to.
Unfortunately, for web design companies like TCRM, it just is not possible for us to stop whatever we are doing and expend effort in getting every one of our sites up to date and debugged with the latest browser versions. If it’s not IE 8 it’s Firefox 4. Then Chrome etc etc (though Kevin isn’t the fan of Chrome I am). The most stable and cost efficient solution is to aim to be compliant in the last-but-one version of a browser. The knowledge base has grown so fixes are available for most major bugs and the industry as a whole tends to work in the same direction. It’s not perfect, but it’s the best solution for the mess out there.
In the ideal world all browsers will follow the agreed upon standards to the letter and us developers can plan our websites to the standard even before the new browsers are written because they will all act as set out in the standard. In this world cheeseburgers are also free.
Reality is a grim dark world filled with quirks, workarounds and those little CSS bugs which turn a simple menu update into a eight hour slog, by the end of which you question your career choices. I had to deal with one such bug this week. PDF files created on the fly using PHP are a very powerful tool and a useful addition to any website. Even though the file itself is a PHP file, by specifying in the header that the content of the request response is a PDF file, the browser treats it as such. Well this is how it’s supposed to work, and does work like a dream in Firefox. IE doesn’t play by the rules. Rules are for whimps and IE is a big boy with long trousers and everything. IE just looks at the filename in the URL and goes from there. If it sees that the URL ends in .php, it interprets it as a PHP. You can see the problem here. The only working solution for our PDF writer is to create a temporary PDF file and redirect the browser to that. It’s just these little workarounds and fixes which can suck up the effort.
Because of these bugs developers have to react to new browsers coming out instead of planning for their release. Developers have to wait until they get their grubby little hands on the browsers before they can write websites for them as we need to see what quirks and how closely the standards have been adhered to.
Unfortunately, for web design companies like TCRM, it just is not possible for us to stop whatever we are doing and expend effort in getting every one of our sites up to date and debugged with the latest browser versions. If it’s not IE 8 it’s Firefox 4. Then Chrome etc etc (though Kevin isn’t the fan of Chrome I am). The most stable and cost efficient solution is to aim to be compliant in the last-but-one version of a browser. The knowledge base has grown so fixes are available for most major bugs and the industry as a whole tends to work in the same direction. It’s not perfect, but it’s the best solution for the mess out there.
Friday 10 September 2010
TCRM and Web Design Paradigms
So what sort of programmer are you? Do you sit there with your pad of paper working through the logical process of the website drawing arrows, boxes and those little annotations with curving little pointers all over the place? Or are you from the rough side of the geeky tracks? Do you play it fast and loose by hitting the code first and hacking away until you get something that works?
I belong to the former category. The idealist programmer. I like to think and plan through every aspect of the site before even thinking about producing one line of code. I like the boxes with arrows pointing to other boxes, lists of functions sorted by category, and roughly draw entity relationship diagrams complete with crow’s feet. When I do start to code I like proper indentation, good naming conventions and nicely written comments all over the place. But us idealists tend to produce at a slower rate, more concerned with how good the program is rather than the fact it is completed.
Kevin on the other hand, belongs to the latter group. The pragmatic programmer. He sits down in front of a screen and starts coding until a solution is reached. The resulting source is not pretty to look at (indentation is for wimps), can be hard to follow and naming conventions go out the window. I once saw someone’s code (not Kevin’s) in which they had called a variable ‘variable’. It’s that sort of thing that makes me and other idealists like me wince. However, it tends to be the quicker method for getting out the first version and usually results in a working product. Not pretty or elegant, but by god it works! They are pragmatists after all.
So you have an idealist developer from Bridgend and a pragmatic developer from Neath. Neath Web Design verses Bridgend Web Design! You would think that this difference of approaches would lead to many arguments, a lot of yelling and stamping of feet and sulking in the office. When I first thought of writing about this subject I though to call it ‘TCRM and the Clash of the Paradigms’, but the further I got into the content of the post the more I realised how this just wasn’t the case. There are very few actual clashes. No raging arguments about function names and third normal form and almost nothing more than a raised eyebrow when it comes to generating JavaScript using PHP echoes (I don’t care. It’s fiddly, difficult to debug and looks bad). Very odd.
It turns out that the best of both worlds for a development team is somewhere in the middle. Staff a team with idealists and you’ll be knee deep in relationship diagrams without a single line of code written with only two days of the project left. Fill it full of pragmatists and you’ll end up with lots of undocumented code that’s difficult to debug and almost impossible to move forward to version two. Get a nice mix and good things start to happen with your products. The pragmatists drive the project forward and the idealists insert a bit more structure. Pragmatists will rein in the idealist’s ever expanding requirements so version one is delivered and the idealist approach will mean version two takes less effort.
It is important to know what sort of programmer you are, and what the other members of your team are like. Would you say you are happy with the balance or is it too in favour of pragmatists or idealists? Don’t be afraid to mix it up. The results are pleasantly surprising.
I belong to the former category. The idealist programmer. I like to think and plan through every aspect of the site before even thinking about producing one line of code. I like the boxes with arrows pointing to other boxes, lists of functions sorted by category, and roughly draw entity relationship diagrams complete with crow’s feet. When I do start to code I like proper indentation, good naming conventions and nicely written comments all over the place. But us idealists tend to produce at a slower rate, more concerned with how good the program is rather than the fact it is completed.
Kevin on the other hand, belongs to the latter group. The pragmatic programmer. He sits down in front of a screen and starts coding until a solution is reached. The resulting source is not pretty to look at (indentation is for wimps), can be hard to follow and naming conventions go out the window. I once saw someone’s code (not Kevin’s) in which they had called a variable ‘variable’. It’s that sort of thing that makes me and other idealists like me wince. However, it tends to be the quicker method for getting out the first version and usually results in a working product. Not pretty or elegant, but by god it works! They are pragmatists after all.
So you have an idealist developer from Bridgend and a pragmatic developer from Neath. Neath Web Design verses Bridgend Web Design! You would think that this difference of approaches would lead to many arguments, a lot of yelling and stamping of feet and sulking in the office. When I first thought of writing about this subject I though to call it ‘TCRM and the Clash of the Paradigms’, but the further I got into the content of the post the more I realised how this just wasn’t the case. There are very few actual clashes. No raging arguments about function names and third normal form and almost nothing more than a raised eyebrow when it comes to generating JavaScript using PHP echoes (I don’t care. It’s fiddly, difficult to debug and looks bad). Very odd.
It turns out that the best of both worlds for a development team is somewhere in the middle. Staff a team with idealists and you’ll be knee deep in relationship diagrams without a single line of code written with only two days of the project left. Fill it full of pragmatists and you’ll end up with lots of undocumented code that’s difficult to debug and almost impossible to move forward to version two. Get a nice mix and good things start to happen with your products. The pragmatists drive the project forward and the idealists insert a bit more structure. Pragmatists will rein in the idealist’s ever expanding requirements so version one is delivered and the idealist approach will mean version two takes less effort.
It is important to know what sort of programmer you are, and what the other members of your team are like. Would you say you are happy with the balance or is it too in favour of pragmatists or idealists? Don’t be afraid to mix it up. The results are pleasantly surprising.
Friday 27 August 2010
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
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
Tuesday 10 August 2010
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.
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.
Tuesday 3 August 2010
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!
Subscribe to:
Posts (Atom)