Closed Bug 12291 Opened 25 years ago Closed 25 years ago

Questions should have "yes"/"no" not "ok"/"cancel"

Categories

(Toolkit :: Form Manager, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED INVALID

People

(Reporter: twm, Assigned: morse)

Details

The form-autocomplete "remember user names and passwords" prompt asks, "Do you want this feature enabled?" with buttons "cancel" and "ok", which should probably be "no" and "yes". This same problem occurs with some other dialog boxes I don't recall.
Assignee: davidm → morse
Component: HTML Dialogs → Autofill
Reassign. An alternative would be to have the buttons be "enable"+"disable"
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
This is a matter of personal preferences. Our UE group wanted all such dialogs to be OK/CANCEL. I went through the dialogs used by autocomplete and decided that there were some that it absolutely didn't make any sense for and I changed those to YES/NO, despite UE's protest. This particular one I felt could be acceptable as OK/CANCEL so I left it. Unless UE comes up with a coherent scheme as to which ones should be YES/NO and which should be OK/CANCEL, it will remain as it is now.
Here's a coherent scheme to give to UE. If it asks a question, give an answer such as Yes/No. If it is performing an action, use OK/Cancel.
Is a message such as "Incorrect key, do you want to try again?" an action or a question? You can consider the process of "trying again" to be an action. So in that case I use OK/CANCEL. In fact, if you consider this to be a question, then give me an example of what you consider to be an action. With some realization that I was in the gray zone, I considered enabling the autocomplete feature to be an action so that is why I used OK/CANCEL in the particuar dialog referred to in this bug report. But you could argue that it is a question as well. On the other hand, I consider the dialog that says "Do you want to capture this form?" to be a question and so used YES/NO in that case. As part of the process of trying to come up with a coherent scheme, go through all the dialogs put up by wallet.cpp, singsign.cpp, and nsCookie.cpp and determine which kind of buttons to use in each case. To find the dialogs, search for "Confirm" in those files. If you find any calls to ConfirmYN, those are cases which currently use the YES/NO dialogs, and the others use the OK/CANCEL dialog. If you can then present me with a list of which dialog to use in each case, and I feel it is more coherent than what I have (I promise to be impartial -- I have no axe to grind here), I'll make the changes. If I disagree with it, then I'll reassign the bug to UE (german@netscape.com) and let them make the call.
Firstly, I apologise for the attitude in my last comment. In some cases it seems as if UE are pushing consistency to the detriment of the user, although I may well be hearing a garbled message through the transmission of the message through several people. I must confess that due to this attitude I didn't look too closely at the particular question this involved, but I did after submitting. I now think the real problem is that you've phrased it as a question yet are buttoning it like an action. While I think "Enable This Feature"/"Cancel" would be best, UE would probably prefer the text to be "Press OK to enable this feature." and have "OK"/"Cancel" buttons, and I would be happy with that. As for the "do you want to try again", I'd say "Retry"/"Cancel", but again, you could have the text say "Press OK to retry." and have "OK"/"Cancel".
Hey, no apology necessary. If my reply in any way gave the impression that I was reacting to an "attitude" then I should be the one apologizing for poor choice of words That was not my intent. The problem with UE here is that they made a decison over a year ago to use OK/CANCEL and since then have totally withdrawn themselves leaving us to fend for ourselves. Well maybe that's a blessing if now we can come up with something coherent. So come up with a complete list and lets see if we can reach an agreement between us. If so, I'll take UE's silence as meaning they no longer care and I'll make the changes. But I would suggest we try to stick to just two dialog boxes -- a YES/NO and an OK/CANCEL -- and not invent new ones like RETRY/CANCEL. That will reduce the implementation effort involved.
Action Confirmations: These are confirmations that are needed in order to proceed with an action. - There are two options - one to proceed and one to cancel the action. - The cancel button should be called "Cancel". - The proceed button might be named "OK", "Confirm" or a name indicative of the action, depending on UI standards. - If the button is not indicative of the action, text in the confirmation should explain what will happen by clicking on the proceed button. - These should never ask an explicit question - rather, they are an implicit question as to whether to proceed. - It may include a "never seek confirmation again" question where it makes sense. Action Questions: These are explicit questions that require an answer before completing an action. - There is a cancel button. The cancel button is not an answer to the question, the cancel button is a refusal to answer the question, and termination of the action. - Because cancel is not an answer, there are at least two other choices. These could be either multiple buttons, or an "OK" button accompanied by radio buttons to select the choices, depending on UI standards. Pure Questions: These are questions that are not as a result of an action, or a result of an action that may not be terminated. Hence they don't have a cancel button. Setting Modifications: Changes to settings, "OK"/"Cancel" style. This seems to cover at least what has been discussed so far. It leaves scope for UE to use OK/Cancel. It covers what I've said above, this bug being an action confirmation, and determines that bug #8082, which you've converted to Yes/No, is a "pure question" and hence should not have a "Cancel" in the absence of the ability to cancel submitting the form. As for not using "Retry"/"Cancel", you need to parameterise the dialog by the specific action involved either way, whether it is in static text or button text. Is it easier to do this in XUL with static text? I figure you're going to have platform-specific XUL fragments, templates, overlays or whatever it is you're using these days that handle common button combinations in the platform order, so if these can't be parameterised by strings, it probably is easier to do it your way. Of course the best solution is for these to be parameterisable. =)
No, I wasn't saying you were reacting at all, I was just apologising preemptively. Reading it again, it probably wasn't even obvious to anyone what my emotional state at the time (you know, like with e-mail). Anyway, as an addendum - if the answers to action questions must be radio buttons and an "OK" rather than a bunch of buttons, then to be consistent the same must hold for pure questions! This makes the situation look rather silly, but there you are!
Status: RESOLVED → VERIFIED
No comment.
I should probably take this to the newsgroups and see what people think.
Product: Core → Toolkit
QA Contact: cpratt → form.manager
You need to log in before you can comment on or make changes to this bug.