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.
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-
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. ***
@ 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+.
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!
Copied the file /mail/locales/en-US/chrome/messenger/msgmdn.properties to suite/locales/en-US/chrome/mailnews/msgmdn.properties
same code as the last one but patch was made using different diff arguments
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.
(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: 11 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.