There should be a minumum amount of learning on behalf of a new user when they first use a piece of software. Interfaces should be intuitive and pleasing to the eye - uncluttered and fresh.
When designing the structure of a piece of software it is important to keep certain things in mind. Below is a list of rules that should be adhered to as much as possible if one is to design and implement a truly well written piece of software.
| Modularity: | Write simple parts connected by clean interfaces |
| Clarity: | Clarity is better than cleverness |
| Composition: | Design programs to be connected with other programs |
| Separation: | Separate policy from mechanism; separate interfaces from engines |
| Simplicity: | Design for simplicity; add complexity only where you must |
| Parsimony: | Write a big program only when it is clear by demonstration that nothing else will do |
| Transparency: | Design for visibility to make inspection and debugging easier |
| Robustness: | Robustness is the child of transparency and simplicity |
| Representation: | Fold knowledge into data, so program logic can be stupid and robust |
| Least Surprise: | In interface design, always do the least surprising thing |
| Silence: | When a program has nothing surprising to say, it should say nothing |
| Repair: | Repair what you can ? but when you must fail, fail noisily and as soon as possible |
| Generation: | Avoid hand-hacking; write programs to write programs when you can |
| Optimisation: | Prototype before polishing. Get it working before you optimise it |
| Diversity: | Distrust all claims for one true way |
| Extensibility: | Design for the future, because it will be here sooner than you think |
