In all the dialogs that requires the user to enter text, the button the either activates or OK'es the action should first become available when the user actually enters some text. Like the Search -> Find on This Page... dialog where the Find button only is avaiable when the users has entered some text. Many places this is not the case, like in Bookmarks -> File -> New Bookmark
Actually, the button should be available if the text field has content, not just when the user enters content. In the case of the Find dialog, for example, the field might be pre-filled from the previous search. This should probably be an overlay of some description, linking the contents of the text field to the state of the button, so it can be applied to any dialog you like. I have mixed feelings about this -- fixing it would be a usability plus, but it could also hide a number of bugs (henceforth reproducible only through scripts or something similarly obscure) where certain functions accepted null input when they shouldn't.
Summary: Button first available when user enters text into input field → Only make dialog button available if text field has data
The usability benefit of this suggestion is somewhat dubious. If you make it a general rule, as described here, that any dialog which requires user input should disabled the OK button until input or content has been received, then you're bound to wind up in a situation where a user has filled in some, but not all fields in a dialog and doesn't know why they can't click OK. There's no recourse but to click cancel and start again or give up. Even in a dialog that has only one or two controls, it can be frustrating when a particular control is disabled and there's no way to find out why. On the other hand, if the OK button is enabled, clicking it prematurely can put up an error dialog specifying exactly which piece of information is missing and providing the opportunity to go back and fill it in. Resolving as INVALID since I think the current behavior is more usable (provided we catch errors when they occur!).
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
So I file individual bugs on dialogs where I think Mozilla should use the "no OK before enter text" thingy...
bdonohoe: If a dialog relies on error messages to tell the user what still needs filling in, there's probably something wrong with the design of the dialog. gemal: Yes, go file those bugs. This is invalid really because the best behavior on capturing the Return key varies from dialog to dialog -- in some cases, it would be to accept the input and perform no action (e.g. the Find dialog), in others it would be to beep/flash and then put focus back in the first empty compulsory field. Verifying invalid.
Status: RESOLVED → VERIFIED
For the record, "error" messages are not just a means to prevent crashing or other program failure. Use of an alert to *inform* the user when information is missing is not inherently a bad design; in fact, it can be a *better* design than cramming all the instruction into the dialog because it allows users to learn and then not be bothered with a dialog overloaded with information the next time. Regarding gemal's comment, yes, if there is a particular dialog where it makes sense to dim the okay button until input is received, file a bug and we can all evaluate that particular case.
You need to log in before you can comment on or make changes to this bug.