GUI standards

Part of my work is also coordination with other developers, sometimes even teaching some software development, so I decided that I will add a few rants, hints and comments about common problems to this blog as well.

Todays topic are GUI standards. All modern operating systems have graphical shells, often called window managers, that handle the general behaviour of windows. And nearly all shells have documentation on User Interface Guidelines. A very good lecture on this topic would be the Inside Macintosh volumes, especially the part about Human Interface Guidelines, but the Microsoft Developer Network also has articles dedicated to the user interface. If you want to understand them from a mathematical perspective, you should also start reading about the golden ratio.

Especially for novice programmers, it is quite tempting to implement features that only few other applications have, like dragging a window by clicking anywhere inside it, or having flat buttons without a border that will erupt into colorful 3D buttons when hovering over them with your mouse.

While this may look nice, let's see what different groups of users would thing about this:

• The bloody novice will think: "Ouch, I did something wrong, the form moved when I clicked on it, what should I do?" or ask "Where do I click to continue? I that is a button? I thought they had frames?"
• The average user will think: "Wow, nice, I didn't knew that windows can be moved that way", and will be disappointed when this won't work in other applications. He'll spend more time than usual until he finds out that those texts or gray images are actually buttons when he accidently moved his mouse over them.
• The experienced user won't think about dragging the window any other way than he did thousands of times before - through the title bar; he'll probably even miss this feature. He sees the animation on the button and thinks that it's no wonder this application works only on his new machine, but not on his old reserve one, since the developer didn't really care about memory resources.
• The hacker will move windows using Alt+Space+M only anyway, and be angry at the application because while that fancy button looks so nice, it probably can't be reached using tab or a shortcut.
• The developer will think "Hey, it's cool man, my app is different".

So in the end, the only person who gained something from these features is the developer, while it does nothing (except for maybe irritating him) for the customer.

Default window behaviour is the result of a lot of thoughts of the engineers, as are the guidelines for button heights, distances, default fonts, etc.. Standarized behaviour gives novices especially a much better start into using new applications. There may be valid reasons for some nice unusual features, but always think twice if you want to implement them because they're cool or because they're really helpful. And while it may prove to be more work to get the application look nice, doing it right will also give you some aesthetics that will actually make it feel nice.

This is one example of a bad GUI; fields do not even have the same length, creating a very mixed feeling. The spin buttons, a typical Delphi demo component, have small buttons that look cramped; they could have easily been replaced by comboboxes with a few default values, which would have offered the same comfort of using the mouse to change, but in a nicer overall look. The same width for all fields is also mandatory, a mix like this.

Another example for a nice thing that shouldn't be done. A background image looks nice of course, and different from other applications. But the grey swirls make it more difficult to quickly focus the icon one is looking for.