I recently made a flippant comment of the GNS3 forum:

Rule #27: RedNectar’s guide to programming user interfaces
Never state an option in the negative.

which prompted a request from Jeremy Grossmann

Can you share complete list of all your rules? 😉

So I thought I’d actually write down some of the principles I believe are important to writing programs with a easy to use user interface. This is not a complete list, and it is very GNS3 centric because I wrote it originally on the GNS3 forum. But here it is for what it’s worth. I didn’t quite make 27 rules, but here is a more manageable 7 rules:

Rule #1

Don’t add complexity unnecessarily.

In other words, try and work out the simplest way of achieving what you need to achieve. Also known as Ockham’s Razor or the KISS principle.

Rule #2

Try to predict how the user will intuitively know what to do.

This is the principle which made the iPhone so successful. I’ve also seen this written as “Write programs for people, not for computers”

Rule #3

Consistency

Have a standard approach to every Menu, dialogue and action. Hard to do if multiple people contribute to the development of an application. Even harder if your app is to be used on multiple platforms. Mac users are used to the idea that one an item has been clicked upon it is selected/chosen/applied/done/finished (play around in System Preferences if you don’t know what I mean). Meanwhile PC users expect to be able to click here and there before finally having to click OK before a choice is made – or click Cancel if they decide that they don’t want to change anything after all.

Rule #4

Keyboard First, Mouse Second
Every action that can be performed ought to be implemented via the keyboard. Then add the mouse actions. Not everyone agrees with me on this one, and is definitely one that could not apply to writing apps for a tablet. But I believe it is a rule that should be at least strived for.

This is one rule that is extremely lacking in GNS3 (How do I add a device to my topology without a mouse?)

Rule #5

Provide feedback

Every click that causes any change should provide some visible feedback, even if it is a simple status message on a status bar (GNS3 doesn’t have one of those – although the Console dock does a good job if debug is turned on). I don’t mean that another pop-up dialogue should appear that you have to acknowledge – that just gets in the way (I hope the Cisco UI designers are reading this), but something should happen. For instance, in GNS3 when you go to the Node Configurator and make some changes and click Apply – there is no visual feedback to show that this has happened. It could be something as simple as disabling the Apply button once it has been clicked once (which means that it would have to be re-enabled if another change was made), or a message under the Apply button, or a message in the Console dock. But remember Rule#3.

Rule #6

Warn users if changes will be lost

Similar to Rule #5 – but with more emphasis on confirming with a pop-up if you are about to exit a dialogue without saving changes. This does need some balance though. For instance, in GNS3 when you go to the Node Configurator and make some changes and click Cancel you should expect to loose your changes, you did just click Cancel after all. But if you go to IOS Images and hypervisors and make some changes then click Close then you should be warned that your changes will be lost if you haven’t already clicked Save.

Rule #7

Never state an option in the negative.
There is an option in GNS3 that states:

[ ] Do not use first NIC for connections with the host OS 

This is too confusing.
I remember doing a course at uni that taught us how to write multiple-choice questions and test their effectiveness. One of the rules for writing effective multiple choice questions is also to never ask questions or pose options in the negative. And for good reason. This option would be far better written as:

[x] Reserve first NIC for connections with the host OS

Maybe one day I’ll add some more. But if I do that I may end up violating Rule#1.