Last Friday, I met a prospective client to have a little chat about some problems the business had, what they would like changed to their current system, and what their expectations were.

The meeting went really well, but as is always the case with business, one is not at liberty to discuss various aspects of the requirements process. It may give a competitor insight into current processes, and hence an advantage. Business intelligence is now so important, that most companies are pretty much like a micro version of the Ministry of Defence when it comes to their information and processes.

This was a first for me because I’m usually the back end server guy and not a schmoozer. The meeting went on for over an hour-and-a-half, as we ‘drilled down’ to the requirements process, modelling and analysis. I happened to have had a mock up application prepared, which was excellent because it illustrated my competencies i.e. they could see something that worked, and also a good conceptual springboard. My overall impression was that they were impressed with my demonstration, but I made the mistake of trying to wow them with technical proficiency. I did however make the following observations.

• At no point was the fact that I was using the latest Office 2007 user interface, and really pretty icons come into the discussion. The points I was grilled about (and it was a grilling) was what was missing. Can you make it do this? Can you make it do that? We are unable to proceed with this unless you address issue x and y and z. This basically mitigated the dichotomy in choosing either Windows Forms or Windows Presentation Foundation.
• Always make sure when your are dealing with decision makers and senior management to include lots of statistics. I did have a couple of forms with various statistics, but changed the demo around a bit before the meeting just to structure it better and these were missing. The less you have to explain in a meeting and the more you have to show the better. A picture is worth a thousand words and management love statistics. I will be holding secondary meetings and this is an area I will be fully up to speed on. Charting , gauges, etc.
• Try to make sure that your application is clever, and has features. By this I mean ensure it does as much of the repetitive stuff as possible. Clever insofar as with windows forms for example, the designer does a lot of the tedious stuff like creating a button and aligning it. Features insofar as a mobile phone with a camera, radio, .mp3 player etc
• It is so important that a user gets predicable behaviour from your components. I had not enabled copy and paste in my data grid view and then one of the users tried to it did not work. Not a big deal, but again I needed to explain why not
• Don’t include too many half baked features, that throw unhandled exceptions. My demo threw a few of these and it did not look so good. The program crashed and froze and I needed to restart

So all in all not a too exhaustive list but a post I will revisit and hopefully add to.

If you want a really sophisticated user interface, with a lot of controls and features, then the prime example is Visual Studio (analogous to an aeroplanes cockpit). The Visual Studio user interface allows for a lot of functionality to be made available in a very limited amount of space, i.e. your computer screen. Space is of the utmost importance, and as your applications grow, and more commands and functionality is added, the more difficult it becomes to navigate. The Office 2007 ‘fluent UI’ or ‘Ribbon’ as it’s more commonly known, solved the key problem Office 2003 had developed, which was it had thousands of commands, and it was near impossible to find the command required easily.

In a previous post, I linked to the apotheosis of UI instruction, and I still continue to extol this Video. Definitely one to watch – I have been thanked numerously for pointing people to it. There is just so much you can learn about what to, and not to do, in your applications.

Whilst rummaging around Sourceforge, I came across this docking control. Yes there are commercial versions available, and have been for some time now, but I had not really realised just what it takes to build such a thing. The controls creator, weifenluo, has done a crackerjack job, and created a real quality control. I have tried a few of the commercial ones, and this is right up there with the best them. One can determine easily and immediately that this was a labour-of-love, just by the way it is structured. I now almost always prefer open source software, because there is so much value as a developer in getting to learn how something works. When one works for software companies, the impetus is almost always on purchasing R.A.D components, and shipping software as quick as possible. While one cannot criticise this technique, if you are a junior developer, or are just starting out, ignore the component vendors and get your hands as dirty as possible. If is far much more important that you know how things work as opposed to know how to configure components in the properties pane. Most of these components shield you from using Interfaces and Delegates which are things one needs to be proficient in, to be an efficacious developer.

9 times out of 10 when creating applications, one is required to produce a solution to a problem that is not available as a purchasable component, or you need to modify the component heavily. One soon finds oneself ‘up a creek without a paddle’ whereas, had one known how the component worked, or had an inkling as to the structure and abstraction before one commenced, speedy procurement of the antidote to whatever the problem that is presented is unproblematic.