We are in the middle of implementing some new features in Sente and we are faced with a common design dilemma that I am surprised has not, at least as far as I am aware, been resolved in a standard way across all applications.
The issue is what to do about controls for operations when those operation cannot be performed.
The basic answer in Cocoa is that controls (menu items, buttons, etc.) for operations that cannot be performed should be disabled. Thus, when writing in a text editor, if there is no test selected, the Edit > Copy command is greyed out, meaning there is nothing that can be copied right now.
The problem with this approach is that it does not really help the user very much. They know that they cannot perform the operation, but they do not know why and what they need to do to be able to perform the operation. For me personally, this is one of the most common problems I face when trying out new software. It may be obvious to the developer why the greyed out operation is not available right now, but I am often at a complete loss as to why this would be the case.
I have heard people suggest that you leave the command active (i.e., not greyed out) and pop up an error sheet when the command is invoked inappropriately. The problem I have with this option is that you lose the quick feedback that an inactive control gives you -- you have to go down the blind alley to find out that it leads nowhere. Particularly after you understand when a particular command makes sense and when it does not, deactivating it when it is invalid is helpful.
Another approach I have heard of fakes the deactivation but leaves the command executable. For example, if Copy made no sense, it would appear grey in the menu, but it could still be selected. The developer would then open an error sheet (or something similar) to explain why the command can not be executed. While there is much that I like about this approach (immediate feedback of "deactivation"; simple, consistent method for getting more information) it also has some important problems. One, it is not standard, so most users will not know that they can select an inactive control. Two, it is not supported in the Cocoa frameworks, so it would require quite a bit of development on the part of every developer to make it work. Three, there is no visible indication that an explanation is available, so less experienced users would have to be told that this convention existed.
One more approach is to use the fly-over help on controls to explain when they can be used. This could be very helpful, but... One, it does not work for menu items (they do not have flyover help). And, two, because this is not a standard, many people will not find the messages even where they exist.
So, in the end, I don't think any of these options is good enough and I cannot think of anything better. What I really want is a solution that:
1) is genuinely standard, and this means that it is implemented in the Cocoa frameworks so that everyone gets it "for free" just by following the normal development process and experienced users expect it to be used
2) preserves the immediate feedback of inactive controls
3) is obvious (or at least visible) for users who do not yet know how to get this information
Anyone have any ideas about what such a mechanism might look like? Or do you think I am making too much of this problem and that the existing conventions/tools are adequate?
Michael
Hi Michael,
this comment comes from my experience as an user.
- If I find a greyed out command, I know that it's there and there must be a way to use it. That's usually the starting point for a trial&error session, or, even better, for a quick click&search on the User manual.
- if there is a non-standard behavior, I tend to have more difficulties at finding out how to use it: good computer programs are very predictable, and our skills depend on this predictability.
- non-standard behaviors usually are the prologue for a mess at a later stage. I've used plenty of non-standard programs, and every system/computer upgrade used to break the programs with new patches and non-standard coding needed to be applied. No need to mention that these programs usually have a much more troubled/shorter life than others. The last one I've used is VectorNTI: after it finally broke with Tiger, I swore I would have never used again a program with a PC-like GUI.
waiting for all these brand new features...... :)
Silvo