Concept integrity is a corner stone of software design. It is a means for achieving a uniform and aesthetically pleasing solution, providing consistent behavior from different perspectives. The relevant perspectives depend on the user, maintainer, programmer or other people coming in contact with the system. Each perspective requires attention at different levels and manages different complexity of information. This is why the concept integrity meaning is different at each level and why the idea of concept needs clarification in the correct context.
What is a concept?
Extract from wikipedia:
“Concepts are expected to be useful in dealing with reality. A concept is basically the main idea. Generally speaking, concepts are taken (a) to be acquired dispositions to recognize perceived objects as being of a certain ontological kind, and at the same time (b) to understand what this kind or that kind of object is like, and consequently (c) to perceive a number of perceived particulars as being the same in kind and to discriminate between them and other sensible particulars that are different in kind.”
In plain words:
Use the same ideas in the same way, to perform same actions in similar methods
Here are two incorrect fictional examples:
- File open: fopen (handle *, filename, properties)
- File open for readonly: handle = filereadonlyopen(filename)
- Opening a file: use the file -> open menu option
- Opening a template: incorrect use – go to options and list the templates.
As seen, both examples display similar actions in very different ways, alienating each user. For the programmer, learning how to use each function and knowing they are different in bothering. This can be seen in the reactions to the windows API changes. For the user, finding the templates can be frustrating because the logic need remembering and not finding the action in the assumed place is very annoying. A good sample is the reaction to the ribbon in office 2007.
If you read this far, you should follow me on twitter here.