Open Bug 118684 Opened 23 years ago Updated 2 years ago

Want "Yes/No" for "Return to compose window?" dialog

Categories

(MailNews Core :: Composition, enhancement)

Product:
MailNews Core
Component:
Composition
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: u32858, Unassigned)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011012
BuildID:    

when unable to save a msg in my Sent folder after clicking send I get this
error. "Could not connect to the mail server; the connection was refused", while
also un clear as to if it is my SMTP server or incomming it could not find there
is only an OK box.

Now this next popup asks a question that requires a Yes/No answer, but one has
to guess and chose OK for the answer.
"Send Message Error"
"Your Send operation was sucessful, but copying the message to your Sent folder
failed.  Would you like to return to the compose window? OK/Cancel"

Also just reading that english grammer is the "," really necessary? it seems to
look out of place IMO.


On my test machine I do not actaully read email, so i just configured localhost,
event though it does not have an imap server.  This is due to the fact that its
impossible to have a messenger account without a server.. this would be useful
in my sitution, and maybe others. Something like a "no incomming mail server"
option to click during the wizard process.

Reproducible: Always
Steps to Reproduce:
1.config your IMAP server as a null address
2.send a mail
3.see it fail to save the msg on imap server

Actual Results:  wierd OK/Cancel screen :)

Expected Results:  "nice" Yes/No buttons
This is a request to change the buttons on the error dialog to Yes and No
instead of OK and Cancel.  This definitely nothing critical will be looked into
in the future.
Severity: trivial → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
This is definitely a step in the wrong direction.  Dialogs should be tuned to
the situation at hand, not boilerplated.  For example, the following dialog...

Do you want to remember this decision?
                         [Cancel] [OK]

...does not make much sense.  It would seem that using Yes/No buttons would be a
better idea, and itn this case it would.  But an even better experience is as
follows:

Do you want to remember this decision?
           [Don't Remember] [Remember]

This has tuned the dialog to indicate the EXACT action that will occur when the
user clicks a button.  Here's another example where OK/Cancel fails:

Are you sure you want to cancel the search?
                              [Cancel] [OK]

While Yes/No would be an improvement here, the better experience would be:

Are you sure you want to cancel the search?
          [Continue Search] [Cancel Search]


To see a correctly done dialog in Mozilla, create a new Mail Message.  Type in
some foo and try to close the message.  The resulting dialog box...

Message has not been sent.  Do you want to 
save the message to the Drafts Folder?
[Don't Save]               [Cancel] [Save]

...clearly indicates what will happen when the user clicks a button.  The
[Cancel] button is a bit ambiguous, but most computer users understand what
happens when you click there, and even if you don't know for sure, it's safe to
click it.

In short, please do not implement a boilerplate yes/no dialog in Mozilla.  If
the situation does not fit the standard OK/Cancel box, please tune the box to
fit the situation.

Perhaps a better solution would be to implement a more versatile reusable dialog
in which you could define the alert message, the titles of the three buttons,
and the function to call (passing the pressed button) when the dialog is dismissed. 
-->varada
Assignee: ducarroz → varada
I agree with all the comments by Matt, I had forgoten this bug i had submitted!

Please consider this important, imagine using mozilla when english is not you
native lanuage AND tring to understand these dialogs :)

JG
I disagree with Comment 2. and i wrote a nice long comment explaining why, but 
my browser crashed

< Do you want to remember this decision?
<           [Don't Remember] [Remember]
But I can't remember what decission I'm supposed to tell the computer to 
remember. That's *BAD*. You've wasted two lines and ten words helping me forget 
the issue.

> Sending mail in Rich Text Format with lots of microsoft only extensions.
> [Send + set RTF as default] [Send] [Stop]

Cancel in sending mail dialogs is bad. Especially ours.  It's behavior is so 
unpredictable that we should avoid it.

< Are you sure you want to cancel the search?
<          [Continue Search] [Cancel Search]

If you ask a yes no question, then the only acceptable answers are Yes and No.

> Currently searching foopy. In order to do anything else, you will need to 
interrupt this search.
> [Continue search] [Cancel search]

Note that i use 'cancel' here because in this case for some stupid reason this 
hypothetical dialog will kill my search and require me to search again if i 
want more results. If it was nice, it would let me click [Pause Search] which 
would also be an interruption (albeit, much more welcome).  Note that search 
should be lowercase. and using the same Letter to begin both buttons is *BAD* 
especially given the us education system taught students to guess words by 
first letter.

[Continue] [Stop] would probably be better.
Whiteboard: DUPEME
My comment was not meant to address real situations in Mozilla, but generic
cases where Yes/No might be better than OK/Cancel.

My point remains:  Yes/No should never be used.  Instead, the buttons should be
labeled with the action that will be taken when clicked.

The "Do you want to remember" dialog example would almost never occur, and
should, in fact, only exist as a check box on a dialog about the decision at hand.

> If you ask a yes no question, then the only acceptable answers are Yes and No.

No.  Even if the answer is, in effect, yes or no, the buttons should, once
again, be labeled with the action that will be taken when you click the button.

------------------------------------------
Are you sure you want to delete this item?
                   [Don't Delete] [Delete]
------------------------------------------

Most dialogs boil down to a yes or no question.  Even if it does, you should
never use Yes/No.  A side note: in this case, [Cancel] could be used instead of
[Don't Delete] (to save space), since its meaning would be clear.

> Currently searching foopy. In order to do anything else, you will need to 
interrupt this search.
> [Continue search] [Cancel search]

This is a badly formed dialog.  A dialog that requires a user to make a decision
should ultimately ask the user a question.  When rephrased, your example is
indeed another yes/no dialog.

--------------------------------------------------
Doing this will cancel your search.
Are you sure you want to cancel searching "Foopy"?
                 [Continue search] [Cancel search]
--------------------------------------------------

Note that your button labels work perfectly.

I will once again call for an extended, reusable dialog box that allows more
customization than a boilerplate dialog box.  Here is the standard alert sheet
function available in Cocoa Mac OS X applications.

void NSBeginAlertSheet(NSString *title, NSString *defaultButton, NSString
*alternateButton, NSString *otherButton, NSWindow *docWindow, id modalDelegate,
SEL didEndSelector, SEL didDismissSelector, void *contextInfo, NSString *msg, ...)

Explanation:
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Functions/AppKitFunctions.html#//apple_ref/c/func/NSBeginAlertSheet

Something along these lines would benefit Mozilla's UE much more than another
convenient boilerplate panel.
Whether Yes or No should be provided in general is bug 130789, it's not this 
bug. This bug is (mainly) about the particular alert which appears when copying 
to the Sent folder doesn't work. (The suboptimal error message when failing to 
connect to a mail server should be filed separately.)

In general, asking a question in an alert where one of the options is not 
`Cancel' should be avoided, and that's the case here. Therefore, I suggest that 
mail/news copy the message to the Sent folder *before* trying to send it. 
Leaving a message unsent while I sort out permission problems (or whatever) 
with my Sent folder seems much preferable to sending a message and then forcing 
the user to save to a text file if they want a permanent (and permanently 
disparate) record of it.

Therefore:
,-------------------------------------------------.
|:::::::::::::::::::::::::::::::::::::::::::::::::|
|-------------------------------------------------|
|   _                                             |
|  (X)  The message "Re: Mail/news alerts" cannot |
|       be copied to your Sent Messages folder,   |
|       because {reason}. Do you want to send the |
|       message anyway?                           |
|                                                 |
|                           ( Cancel ) (( Send )) |
`-------------------------------------------------'
Hardware: PC → All
Arg, that should be /!\, not (X). Sorry.
I agree, but I feel that the label "Don't Send", rather than "Cancel" makes a
user much more secure in what's going to happen when they click that button. 
More of an experience thing than interface.


---+-------------------------------------------------+---
   |   .                                             |
   |  /|\  The message "Re: Mail/news alerts" cannot |
   | /_'_\ be copied to your Sent Messages folder,   |
   |       because {reason}. Do you want to send the |
   |       message anyway?                           |
   |                                                 |
   |                   ( Don't Send ) ((   Send   )) |
   +-------------------------------------------------+
See also Bug 142737.

taking all of varada's bugs.
Assignee: varada → sspitzer
Dupe of bug 41833?
Comment #2 appear to be offbase. What possible justification is there to ask a
yes/no question and not provide for yes/no responses?
Product: MailNews → Core
*** Bug 150715 has been marked as a duplicate of this bug. ***
The real problem with this specific dialog isn't the Yes/No, it's the fact that the user has to worry about losing data.  In this case, the message has been Sent, but the copy can't be transmitted to the IMAP server -- and the option is given to "return to the compose window"?  How lame; nothing useful can be done from that window, other than save the message as a Draft.

Instead, the message should automatically be saved in a Local Folders 'Sent' folder (maybe a subfolder with the account name), and the user alerted that 
this has happened (with a single OK button) so she can manually move the 
message to the online folder when the server is next available.  

Automating that last step would be a nice bonus but probably not worth the effort.
Assignee: sspitzer → nobody
QA Contact: sheelar
Summary: Use of OK/Cancel when Yes/No is the answer required → Want "Yes/No" for "Return to compose window?" dialog
Whiteboard: DUPEME
*** Bug 337439 has been marked as a duplicate of this bug. ***
QA Contact: composition
Product: Core → MailNews Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.