Closed Bug 249684 Opened 20 years ago Closed 16 years ago

Return Receipt prompt should not use OK/Canel

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
trivial

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: ali, Assigned: endico)

References

Details

(Keywords: polish)

Attachments

(2 files, 2 obsolete files)

Currently when Thunderbird wants to as the the user if it can send a reply to a
return receipt request, it asks something to the effect of the following:

"Do you want to send a return receipt?" (not the exact words, I know)
[OK] [Cancel]

The point is that either the buttons should be [Yes] [No], --or-- we should
rephrase the question so that OK/Cancel options make sense.
This fixes a very minor issue.
Attachment #152988 - Flags: review+
Comment on attachment 152988 [details] [diff] [review]
Quick fix to change dialog

Sorry I goofed setting the review flag the first time. Hopefully this is right.
Attachment #152988 - Flags: review+ → review?(mscott)
Attachment #152988 - Flags: superreview?(bienvenu)
this is also for application suite and for all platforms
OS: Windows XP → All
Attachment #152988 - Flags: superreview?(bienvenu) → superreview+
Attachment #152988 - Flags: review?(mscott) → review?(dmose)
Comment on attachment 152988 [details] [diff] [review]
Quick fix to change dialog

In general, Yes/No prompts are considered poor UI, because users often
reflexively click Yes, and then regret it afterwards.  The recommended solution
is usually to use specific verbs as buttons.  In this case, perhaps something
like "Send Receipt" and "Ignore Request"?
Attachment #152988 - Flags: review?(dmose) → review-
Hardware: PC → All
See also Bug 142737 (this bug here is more or less a dupe of that one).
See also Bug 221615 which is about changing the UI to be a bar like the one for
junk mail. If that's fixed, this becomes irrelevant.
*** Bug 320252 has been marked as a duplicate of this bug. ***
QA Contact: front-end
Severity: minor → trivial
Assignee: mscott → nobody
@ Dan Moosedale. That is a good point, but it is even worse to have the prompt configured in a way that leaves the user confused about what will happen if he clicks either button. 

Perhaps "Send Receipt" and "Do Not Send" is acceptable.
The current UI is both high-visibility enough and confusing enough and easy enough to fix that this should block Thunderbird 3, adding blocking+.
Flags: blocking-thunderbird3+
The patch has a review- and superview+.  So is the current patch good enough?  Does it need an approval request?  Checkin-needed keyword?
No, it needs a new patch.  Since we now have user experience expertise around, I'm gonna start by assigning to clarkbw and asking him to either give ui-review+ to my UI suggestion in comment 4, or to propose something different.  After that, someone will need to come up with a patch based on Bryan's comments and then get that reviewed.
Assignee: nobody → clarkbw
(In reply to comment #4)
> (From update of attachment 152988 [details] [diff] [review])
> In general, Yes/No prompts are considered poor UI, because users often
> reflexively click Yes, and then regret it afterwards.  The recommended solution
> is usually to use specific verbs as buttons.  In this case, perhaps something
> like "Send Receipt" and "Ignore Request"?

Yes, please use verb (action) buttons instead of Yes/No
( Ignore Request ) ( Send Receipt )

Also I spent a bunch of time working on return receipt designs a while ago.  ( https://wiki.mozilla.org/User:Clarkbw/Return_Receipt )
Summary: Return Receipt prompt should ask Yes/No, not OK/Canel → Return Receipt prompt should not use OK/Canel
While we'll definitely block 3.0 on getting better verbiage here, I suspect we wouldn't block on getting the full UI Bryan described implemented, but he may have a different opinion on that.  Reassigning to nobody to indicate that this bug is free for the taking...
Assignee: clarkbw → nobody
Indeed, take the link posted as future direction possibilities for those so inclined.  This bug should remain about making this simple fix happen.
The original dialog looks like this.
------------------------------------------------------
| Confirm
| 
| The Sender of this message has asked to be notified
| when you read this message.
| Do you wish to notify the sender?
|                                 ( Cancel )(   OK   )
------------------------------------------------------


My patch changes the wording in the buttons from 'Cancel' to 'Ignore Request' and from 'OK' to 'Send Receipt'.

I also added an extra line break before the 'Do you wish' line since the way it is now looks like a mistake.

The reviewer should double check the ConfirmEx function call to make sure the parameters are right. I followed the pattern of the original code, and it works, but i'm not sure why because it doesn't match the documentation or any of the other ConfirmEx calls I noticed in mxr. The second parameter should be the title of the dialog but it seems to be getting skipped. Also there seems to be an extra parameter at the end for the  return value. Maybe ConfirmEx got re-declared somewhere but I don't see it in MXR.

If I understood how this worked, I'd be tempted to remove the title since the word 'Confirm' doesn't seem to be adding much there. Or maybe it only looks out of place on the Mac because of the odd way dialogs interact with the spiffy new skin.

Here's the current ConfirmEx call
http://mxr.mozilla.org/comm-central/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp#397

Here's documentation on ConfirmEx
https://developer.mozilla.org/en/nsIPromptService#confirmEx
Comment on attachment 351636 [details] [diff] [review]
Fix with verbs & add line break to message

the first sad thing is that you need to make the corresponding string change to the corresponding suite properties file (suite/locales...) which you can find with mxr.

If you attach a new patch w/ that change, I'll apply it and check it out.
Attachment #351636 - Flags: review-
thx for taking this on!
Attached patch FixWithVerbs+suite (obsolete) — Splinter Review
Copied the file /mail/locales/en-US/chrome/messenger/msgmdn.properties to suite/locales/en-US/chrome/mailnews/msgmdn.properties
Attachment #351636 - Attachment is obsolete: true
Attachment #351640 - Flags: review?(bienvenu)
same code as the last one but patch was made using different diff arguments
Attachment #351640 - Attachment is obsolete: true
Attachment #351655 - Flags: review?(bienvenu)
Attachment #351640 - Flags: review?(bienvenu)
The other sad thing is that you must also bump the localization key name when you change the text, otherwise localizers can't keep up. (Must change "MsgMdnWishToSend" to something else.)

Since the buttons are self explanatory now, do we need the "Do you wish to notify the sender?"-part ?
Comment on attachment 351655 [details] [diff] [review]
FixWithVerbs+suite -p -u8

I don't think adding a second newline warrants a new string name...

thx for the patch, Dawn - asking for sr from Neil.
Attachment #351655 - Flags: superreview?(neil)
Attachment #351655 - Flags: review?(bienvenu)
Attachment #351655 - Flags: review+
(In reply to comment #16)
> The reviewer should double check the ConfirmEx function call to make sure the
> parameters are right. I followed the pattern of the original code, and it
> works, but i'm not sure why because it doesn't match the documentation or any
> of the other ConfirmEx calls I noticed in mxr. The second parameter should be
> the title of the dialog but it seems to be getting skipped. Also there seems to
> be an extra parameter at the end for the return value. Maybe ConfirmEx got
> re-declared somewhere but I don't see it in MXR.
You're looking at the wrong ConfirmEx; this is the nsIPrompt version.
Also, the C++ IDL calling convention uses nsresult return codes instead of exceptions and extra out parameters instead of return values.
Attachment #351655 - Flags: superreview?(neil) → superreview+
fix checked in, thx, Dawn.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Assignee: nobody → endico
Target Milestone: --- → Thunderbird 3.0b2
You need to log in before you can comment on or make changes to this bug.