My client has designed a screenshot showing how they would like their application to look. The guy who made it is fairly good with Photoshop and it has rollovers and tabs with 3D effect and everything. However, whilst he is a fairly capable amateur designer, he doesn’t have a lot of knowledge of usability and has resulted to the standard muddling through approach. The design uses frames; employs a fair amount of javascript; will require frames to be kept in sync with each other and uses a JS tree view control.

Typically with the muddling through approach, a lot of it is fine. Syncing frames all the time will make the application more complicated as each page has to work out where what goes. The tree view is a worry as well. What if somebody hits it with a browser that can’t handle it? I will build it using DOM methods and CSS so it’s future proof, but I bet there are going to be people that use Netscape 4 to browse this application. Because it’s a functional application I believe it’s much more important that people can access it reliably. It’s OK when you can’t hit the latest Kylie website, but if you work in say, a hospital or a garage, you don’t want to be upgrading your browser just to get your job done.

Somehow I need to bring these issues into discussion without making the designer think I’m having a go at his design. I also admit that there is a side motive, some of the stuff he has asked me to do will be time-consuming to implement, so I’d rather not do it. My reason for this is not just laziness, they could use my time better to create a more functional application.

The dilemma is working out how much I’m hired to talk and how much to do. Often I’m hired to build and advise but that isn’t always the case. It’s not black and white, of course, some things are open for debate, others are resolutely not. I get the feeling that the design of this site is not up for debate and there’s only one way to find out. It’s not my favourite part of the job and I think that it might be worth looking at a course in client management or something. The reason it’s so hard is that when I’m in a meeting my primary goal is to please the client. When I’m coding, it’s to build an application quickly and without bugs. That means that I think of something and when I come to discuss it my view has been changed subtly by the desire to please my client.