102643 - resolve UI issues for ctrl+enter feature for sending mail.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[(not reading, please use [e-mail] instead)]

resolve UI issues for ctrl+enter

here are the outstanding UI issues that I know of.

1)  once we add a new pref to disable ctrl+enter (see #20336), do we add pref 
UI for that?  (let's call it "mail.accel_key_send.enabled" for now)

2)  do we want to show the warning dialog when the mail.accel_key_send.enabled 
is true?  we've got a pref (mail.warn_on_send_accel_key) that's hooked up to 
the current warning dialog so that user won't see it again.  (currently 
defaulted to true, so the user sees it.)  note, once it is set to false, 
ctrl+enter will still send the message, it just won't warn you.

3)  do we add pref UI for mail.warn_on_send_accel_key, so the user can get the 
warning dialog back?

4)  is the text in the current warning dialog correct?  (here comes a screen 
shot)

any other issues?  please list them here.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: screen shot of current dialog

Comment 2

[(not reading, please use [e-mail] instead)]

when jglick helps us resolve these UI issues, I can hand it off to roc or 
varada.

Comment 3

[:deanis74]

The dialog shouldn't have a question mark icon, as this is discouraged by both
MS and Apple.

Comment 4

[jglick]

Attachment: Confirm

Comment 5

[jglick]

Attachment: Idea of what Prefs might look like, open to suggestions

Comment 6

[robinf]

In the prefs panel: instead of the term "accelerator", can we substitute
"keyboard shortcut"?

Comment 7

[scottputterman]

Here's my opinion.

Don't allow Ctrl+Enter to be turned off.  Just make it the accelerator.

Then, have this confirm dialog defaulted to on with the ability to be turned
off.  Make this a pref somewhere in the mailnews prefs.

This way, Ctrl+Enter is an accelerator. Those who want it are happy.  Those who
are worried they will accidentally hit it can be warned by the confirmation
dialog.  I don't think we should have a pref to control an accelerator.  

Comment 8

[:deanis74]

Apparently nobody heard me the first time: The dialog shouldn't have a question
mark icon.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/dlgboxes_4f8z.asp

"[T]he question mark message icon is no longer recommended, because it does not
clearly represent a specific type of message and because the phrasing of a
message as a question could apply to any message type. In addition, users can
confuse the message symbol question mark with Help information. Therefore, do
not use this question mark message symbol in your message boxes. The system
continues to support its inclusion only for backward compatibility."

So, like, get rid of it, eh?

Oh, and I agree with putterman on how to work this pref.  Just because we store
it as a pref doesn't mean that it has to appear in the prefs dialog.  The only
problem is, if it's not in the prefs dialog how does a user re-enable it once
it's disabled?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

==putterman

Comment 10

[Matthew T (active 1999-2002)]

+----------------------------------------------------------+
|::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
+----------------------------------------------------------+
|   .   Are you sure you want to send "Re: Too many alerts | <label>
|  /!\  in mail/news" to the 3 chosen recipients?          |
|  """                                                     |
|       The message contains no attachments.               | <description>
|                                                          |
|                                                          |
|       [/] Ask me whenever I type {accel}+Enter           |
|                                                          |
|                                    ( Cancel ) (( Send )) |
+----------------------------------------------------------+

Comment 11

[jglick]

I agree with putterman as well. Show the confirmation dialog only when Sending 
with accelerator. Pref to turn conf dialog back on, but not to enable/disable 
the accelerator.  

But I was gathering the consensus from bug 20336 was a pref for both, hence the 
pref panel screenshot i posted.

As for the question icon, we seem to be using it someone consistency in the 
product when asking the user to confirm something. I'm not saying that is 
correct, just that we seem to use it somewhat consistently in this situation. I 
assume you are recommending the warning "!" symbol instead.

Comment 12

[:deanis74]

jglick: Sorry, was in a weird mood last night.  Yes, the warning icon should be
used instead... "Alerts the user to a condition or situation that requires the
user's decision and input before proceeding"

(I know mpt's on a personal crusade to erradicate the question mark)

And to top it off I had the wrong URL, too.  The correct one is:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch09f.asp

Comment 13

[Kathleen :Brade]

Jennifer--would there be any way for me to permanently disable that keybinding or 
would I always see the dialog so I could cancel the send?  

My fear is that while I was typing, I would inadvertently press accel-enter and 
then press enter again (maybe I was trying to get multiple blank lines but didn't 
release the control key quick enough) which would dismiss the dialog and send the 
message even though I hadn't finished composing the message.

More importantly, I don't want to lose my typing when the dialog comes up if I 
never want to send with that keybinding.

I see 3 scenarios:
 * the person who likes keybinding to send and never wants the dialog to come up
 * the person like me who doesn't want the keybinding to do anything (no dlog)
 * the person like my dad who would want the dialog to ask him every time

Maybe the checkbox is the wrong type of control to use to address these 3 
scenarios?

Comment 14

[Ben Ruppel]

I think mpt's dialog box is really spiffy, what with its subject and recipient
number info included.  I especially appreciate the "This message contains no
attachments" part, as I continually make a fool of myself by telling people I'm
attaching something, and forgetting to attach it before sending :)

Comment 15

[Simon Fraser [no longer active]]

I second brade's comments. It's way too easy to hit Ctrl-Enter, then Enter again 
and still send by mistake.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If that's so, how about making the default button in the dialog box be "cancel"?

Comment 17

[scottputterman]

I should've cc'd myself.

I guess what I don't understand is why it's so easy to hit ctrl-enter and then
enter again. I would think that would be pretty unlikely.  I'm pretty sure I've
never accidentally typed that combination (never done it on purpose either). 
Not that my experiences should be the basis of anything (and admittedly I'm
Windows-centric and don't know how likely it is to hit it on other platforms).

If someone wants to, I have no problem with making a hidden pref to turn it off,
but I don't think it should be exposed in the UI.  At least not until we decide
to have a UI to expose turning other mail keybindings on and off.

Ctrl-Enter will be turned on in the NS build whether it's in the Mozilla or NS
trees.  I think it makes sense for the Mozilla build as well, for the reasons
I've mentioned earlier.  

Comment 18

[jglick]

Attachment: Confirm send as visible pref only.

How about we go with enabling/disabling the confirmation pref as visible and
turning off the accelerator completely as a hidden pref?

Comment 19

[Olga]

Jennifer, your first suggestion from bug 20336 seems to me much more appropriate
than last one.
1. I vote to have by default 'ON' the option to enable shortcut! Otherwise, our
shortcut showed next to File|Send menu item looks like not working. All this
story started with necessity to have well known shortcut.
2. Also to have default focus on 'Cancel' in the confirmation message. Again, it
is for accidental pressing our shortcut combination.

Your first prototype covers main expectation and Brade’s scenarios at 11/09/01:
 * the person who likes key-binding to send and never wants the dialog to come
up – Only first check box (Enable Ctrl+Enter) is checked.
 * the person like me who doesn't want the key-binding to do anything (no
dialog) – Uncheck first check box.
 * the person like my dad who would want the dialog to ask him every time – Both
check boxes are checked.

Confirmation msg will never appear if shortcut option will be disabled.  That’s
why it is good to have second check box depended on first one.

Comment 20

[Ben Ruppel]

Ugh, I think putting the default to cancel is over-zealous and negates the
convenience of having a shortcut in the first place.  Note that in the find
dialog, hitting ctrl-enter does not initiate a find.  If this behavior is
consistent, hitting ctrl-enter multiple times won't accidentally send a message.
 You'd have to hit ctrl-enter, then switch to enter alone.  

Comment 21

[:deanis74]

"It's way too easy to hit Ctrl-Enter, then Enter again"

Oh, please.  No it's not.  Again, we're trying to take into account every single
user here.  Anyone that "accidentally" hits Ctrl+Enter isn't going to hit Enter
again before s/he has a chance to read the dialog.  And heavily-intensive
keyboard users such as most of the people that have commented on this bug have a
pretty good idea of what they're doing.

Comment 22

[Simon Fraser [no longer active]]

"It's way too easy to hit Ctrl-Enter, then Enter again"

Given the way that our dialogs are created asynchronously the first time they 
appear, it *is* very easy to do this, since you'll have hit the second Enter 
before the dialog shows up, yet the dialog respond to that Enter key. For another 
example, see bug 83185.

Comment 23

[Olga]

Refer to bug 106327 regarding text next to menu item: File|Send Now or
File|Send Later.  Only Mac has 'Return' button on the keyboard. Other systems
have 'Enter'.

Comment 24

[Matthew T (active 1999-2002)]

Simon, using the keyboard to activate controls which haven't been drawn yet
isn't something unique to our UI, it also works with the native alerts used in
4.x and elsewhere. Your problem is possibly various other things to do with
Mozilla's alerts, such as them being too slow to come up, or some keyboard
shortcuts being subject to auto-repeat when they shouldn't be.

I find it extraordinary that people who had so much grief with accel+Enter in
3.x and 4.x ended up being interested in Mozilla mail/news at all ...

Comment 25

[(not reading, please use [e-mail] instead)]

accepting, moving to 0.9.9, since nsbeta1+

Comment 26

[morpheus]

In the meantime, is there a way to actually enable the accelerator?

Comment 27

[Sheela Ravindran]

changing qa contact to olga

Comment 28

[(not reading, please use [e-mail] instead)]

> In the meantime, is there a way to actually enable the accelerator?

the accelerator is enabled, but there is a bug that prevents it from working on
win32.  see (#20336 and #50255)

I've got a fix in hand for this bug, to make the prefs look like 
http://bugzilla.mozilla.org/attachment.cgi?id=57281&action=view

I'll attach the patch and a screen shot.

Comment 29

[(not reading, please use [e-mail] instead)]

Attachment: patch

Comment 30

[(not reading, please use [e-mail] instead)]

Attachment: screen shot (on linux)

Comment 31

[(not reading, please use [e-mail] instead)]

fixed.  this has r/sr=bienvenu.

if we want to elaborate on the confirm dialog (as mpt suggests in
http://bugzilla.mozilla.org/show_bug.cgi?id=102643#c10), feel free to spin that
off to another bug.

that bug should be assign to jglick, so she can work out the UI issues and
update the spec.

Comment 32

[Olga]

Verified on Win2K, Linux, Mac OSX - trunk build 02-04-2002.
'Preferences' issues - bug 20336,
Trouble in implementing on Win - bug 50255,
"NOT Ctrl+Return - Ctrl+Enter for Linux and Win", "Cmd+Return should be for
Mac",  - bug 106327.

Comment 33

[Olga]

Wow, I forgot to mark it Verified. I am doing it now.