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)
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.
Reassign. An alternative would be to have the buttons be "enable"+"disable"
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 2•25 years ago
|
||
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.
Comment 3•25 years ago
|
||
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.
Assignee | ||
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
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".
Assignee | ||
Comment 6•25 years ago
|
||
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.
Comment 7•25 years ago
|
||
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. =)
Comment 8•25 years ago
|
||
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!
Comment 10•25 years ago
|
||
I should probably take this to the newsgroups and see what people think.
You need to log in
before you can comment on or make changes to this bug.
Description
•