Thats why it on my "to do" list - and also why it is still on my "to do" list..
Consistency is an interesting concept in ease-of-use studies. On one hand it can make a program easier to use by true beginners through moderately experienced users. On the other, it causes the rule of thirds - in that any one third will dislike what you do consistently, and because you do it consistently they will dislike it intensely. One third, or so, will be indifferent. And one third will like it very much. You can, of course, shift these numbers around depending on context. But it is generally true.
As users grow in experience, consistency becomes a problem to overcome. More and more they want context sensitivity, flexibility, and begin to enjoy and take advantage of the qualifications that make a program rich. The power users begin to demand modes, exceptions, and qualified situations - all of which are the bane of consistency. The concept of consistency gives way to the concept of predictability. In other words, the users do not expect the program to act the same way in all circumstances, so much as they expect the program to act in a predictable way under increasingly complex circumstances.
Even further down the road, predictability begins to pale. Here we get into the extremes of ease-of-use, wherein a program does not act predictably, but rather anticipates surprisingly well. This is, of course, the "holy grail" of ease-of-use, where a program supercedes the expectations of the user. It is inherently dangerous to attempt this, in that the programmer must make "guesses" and assumptions about the user's intent and make the program act accordingly, without narrowing flexibility, or causing the program to become so unpredictable and inconsistent that it cannot operate if the "guess" in incorrect. Its a very delicate balance.
To better illustrate what I am describing, lets use as an example the current thread of this discussion: highlight upon entering an LE.
The most consistent thing to do would be to always highlight or alway not highlight, no matter what the circumstance. That is very easy for the beginner in that it is very predictable. But as we have seen in this thread, it is not always the right thing to do.
The next step is to make it somewhat inconsistent, by either providing a mode toggle, or commands in SBasic. If it is commands in SBasic that would cause it to become inconsistent across LEs - some would highlight for the end user and others would not, depending on whether the database designer predicted it would be useful for the data entry person. If it is a mode, there would need to be a mode indicator on the screen. The data entry person would have to be aware of that indicator. In either case, it is more flexible and powerful (which a kind of ease-of-use), but less consistent.
A step futher (and probably a step too far) would be to make the program so that it predicts the intent of the user without any particular modal action on their part. Does the user always highlight this LE? Do they never highlight this LE? Do they tend to highlight it? etc...
The highlight itself actually attempts a bit of prediction. In any program that does text highlighting, notice that if you highlight text and then press an alphanumeric key - the program (meaning the programmer) assumes that you intend to delete the highlighted portion of text and replace it with what you are currently typing. But if you hit a navigation key, like the cursor arrows, they assume that you only intend to insert text - not replace. For most of us, in most situations, they are mostly right - that would be a pretty good, though not perfect, indicator of intent. But, when working in the arena of high speed data entry, wherein the user's eyes rarely leave the source material they entering, are these assumptions still safe?
Modern program user interface design is full of examples like this, wherein the program must be a balance between consistency and flexibility, power and simplicity. There is a venerable (first appeared in the mid-1960s) text editor called Emacs. It is one of the most powerful programs ever built and also one of the most flexible. Right out of the box, it is actually pretty easy to use. The commands are simple and straight forward. But the program is completely configurable. Every command can be reassigned (and often is), and / or contained in a new macro, invoked by user assigned keystrokes. That means that you can apply for a job claiming to know Emacs backwards and forwards. But when you sit down to that Emacs installation, you cannot possibly predict with any certainty how that particular installation of Emacs will behave.
|