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.