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)
Thunderbird
Mail Window Front End
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 3.0b2
People
(Reporter: ali, Assigned: endico)
References
Details
(Keywords: polish)
Attachments
(2 files, 2 obsolete files)
1.50 KB,
patch
|
dmosedale
:
review-
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
6.17 KB,
patch
|
Bienvenu
:
review+
neil
:
superreview+
|
Details | Diff | Splinter Review |
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.
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)
Updated•20 years ago
|
Attachment #152988 -
Flags: superreview?(bienvenu)
Comment 3•20 years ago
|
||
this is also for application suite and for all platforms
OS: Windows XP → All
Updated•20 years ago
|
Attachment #152988 -
Flags: superreview?(bienvenu) → superreview+
Updated•19 years ago
|
Attachment #152988 -
Flags: review?(mscott) → review?(dmose)
Comment 4•19 years ago
|
||
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-
Updated•19 years ago
|
Hardware: PC → All
Comment 5•19 years ago
|
||
See also Bug 142737 (this bug here is more or less a dupe of that one).
Comment 6•19 years ago
|
||
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.
Comment 7•19 years ago
|
||
*** Bug 320252 has been marked as a duplicate of this bug. ***
Updated•17 years ago
|
QA Contact: front-end
Updated•16 years ago
|
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.
Comment 10•16 years ago
|
||
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+
Comment 11•16 years ago
|
||
The patch has a review- and superview+. So is the current patch good enough? Does it need an approval request? Checkin-needed keyword?
Comment 12•16 years ago
|
||
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
Comment 13•16 years ago
|
||
(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
Comment 14•16 years ago
|
||
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
Comment 15•16 years ago
|
||
Indeed, take the link posted as future direction possibilities for those so inclined. This bug should remain about making this simple fix happen.
Assignee | ||
Comment 16•16 years ago
|
||
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 17•16 years ago
|
||
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-
Comment 18•16 years ago
|
||
thx for taking this on!
Assignee | ||
Comment 19•16 years ago
|
||
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)
Assignee | ||
Comment 20•16 years ago
|
||
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)
Comment 21•16 years ago
|
||
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 22•16 years ago
|
||
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+
Comment 23•16 years ago
|
||
(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.
Updated•16 years ago
|
Attachment #351655 -
Flags: superreview?(neil) → superreview+
Comment 24•16 years ago
|
||
fix checked in, thx, Dawn.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Assignee: nobody → endico
Target Milestone: --- → Thunderbird 3.0b2
You need to log in
before you can comment on or make changes to this bug.
Description
•