Closed Bug 86393 Opened 24 years ago Closed 24 years ago

Get rid of the extra "Sending Message" Window when sending messages

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: Peter, Assigned: bugzilla)

References

Details

Attachments

(3 files)

fix
608 bytes, patch
Details | Diff | Splinter Review
Proposed appearance of mail sent window
43.22 KB, image/jpeg
Details
Proposal of new mail sending progress window
48.16 KB, image/png
Details
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1+) Gecko/20010617 Get rid of the extra "Sending Message" window when sending messages. In recent builds an extra window comes up after pressing the "send" button. This is *completely* unnecessary since it provides NO extra information and only servers to clutter up the screen and taskbar, and confuses the user. What a horrible "feature".
Keywords: mozilla0.9.2, regression
there's a pref to turn it off. I don't know if there is UI for that pref. over to ducarroz.
Assignee: sspitzer → ducarroz
Component: Mail Window Front End → Composition
Soon, this dialog will have a cancel button. Until then, you can avoid this window by setting the following pref into your profile's prefs.js file: user_pref("mailnews.show_send_progress", false);
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Ducarroz, Seth, this dialog has no function - it's just there... displaying a progressbar in the "undetermined" state. Why should we have it there if it useless? We already have the progressbar in the msgcompose window, can't we use that to track the "real" progress of a msg send process? Mpt and I discussed this recently, and apparently he had lots of problems with this window in various situations. CC UI people and myself. Reopening.
Status: RESOLVED → UNCONFIRMED
OS: Windows NT → All
Resolution: WONTFIX → ---
Furthermore, the end-user doesn't (and shouldn't have to) care about prefs.js or any prefs at all. UI that doesn't have a meaning, simply shouldn't exist. Unless there's a very good reason.
Status: UNCONFIRMED → NEW
Ever confirmed: true
4.x for windows had this dialog. When it was not yet implemented for mozilla, bug 28348 was filed to add the dialog. "With the current mail client, I don't feel very confident that my mail has been sent successfully. The only feedback I get is the throbber starting and stopping in the mail window, and you only see that if you that is the window directly underneath the mail compose window, which is not always the case if you are switching windows a lot."
Jglick, I feel confident that there are far many better ways we can achieve that without displaying that dialog! Here is my proposal: 1. Track the progress of the msg send process in the statusbar's progressbar, consistently like other browser window does (instead of popping up a new window for that purpose). 2. Instead of "Copy Complete", display "Message sent" or something similar in the 3panes statusbar when a message has been successfully sent. 3. Provide more meaningful statustexts when we're sending a message like: "Connecting to server..." "Sending attachment..." "Sending email..." "Sending attachment 1 [details] [diff] [review] out of 4" - or something that keeps the user notified.
Originally, what would happen was the message would completely dissappear and IF you had the mozillaMail window open, you could see progress of your mail and confirmation that it was sent successfully. If you didn't have your mail window open, the message would then dissappear, and you'd have no confirmation that it went through okay. Now we have the progress window, but it makes no sense currently because: A) the message window stays open until it is sent B) there is no cancel button (there was at one point). If A and B were to go away, then it would make sense to have the progress dialog. It is important to give feedback as to whether the message was sent successfully.
We already have a statusbar in that dialog that is able to display status and progress. Let's use that.
Even a stupid dialogue with an <OK> button that pops up *AFTER* the message was sent (or failed to send) would be far better than this silly window that is always there. It bothered me in NC4.x and it really bothers me here. Hopefully, at a minimum, someone will have the sense to include a pref UI to turn it off. Ideally, Håkan Waara's suggestion to use the existing status bar is by far the best. If someone really doesn't understand that a self-closing message window means "message was sent", maybe a sound saying "message was sent" would be nice - just please get rid of that superfluous, screen cluttering, confusing extra window. Either we have a statusbar and use it and expect users to use it, or we get rid of the statusbar and pop up little windows all over the place. I say say we use the statusbar - OK?
OK - I think another divergence is required: * Commercial = on by default * Mozilla = off by default
As long as the message window stays visible until the message is sent, I'm fine with using it to display status. Before, the message would just dissappear and remain invisible unless there was an error.
What Kevin proposes is fine with me. All I do/can care about are the Mozilla builds.
Attached patch fix — — Splinter Review
Ducarroz, my patch turns off this pref for new profiles. However, that won't affect the current users so the window will still pop up in the future for them too. I can over-ride the code that is checking this pref... Is that acceptable? If not, what is your proposed solution? Thanks
your patch will turn off the dialog for every body which does not have the pref defined in his/her own prefs file, which it's the case for most of them. For the real fix, you need to change some Netscape private pref file which you don't have access. I will do it my self if this bug get approval. nominating nsbeta1
Status: NEW → ASSIGNED
Keywords: regression → nsbeta1
I'm not sure I understand the purpose of having this as a pref at all. It's not like some user is going to dig it up and use it. :)
The advantage of having a pref is that it allows us to change the behavior in the Netscape or the Mozilla build!
Why do we have to change a "private Netscape pref" in order to fix this bug for Mozilla builds, anyway? Also, will that make the change affect those with old profiles as well? Thanks
hwaara, your fix will work for new and existing profiles. once they upgrade and get a new build, they'll get the new default prefs. when mozilla starts up, it parses all the default prefs.
So what's this secret voodoo pref that I keep hearing about, if my fix fixes it anyway? <shrug> sorry for the spam. :)
You fix turn off the dialog for both Mozilla and Netscape. We need to modify the Netscape pref to overwrite the Mozilla one in order to turn it on for Netscape.
Since that is Netscape specific, do we Mozillians have to wait? How about this: we check in my fix and you file the netscape-overriding part as a bugscape bug?
i like the dialog and would prefer for us to fix it to have a cancel button like 4x.
Ok, i'm sure no one cares about the odd user, but supposing i use both netscape6+ and mozilla, this pref split will eventually mess me up, right? because eventually my user pref (show dialog) will be trashed (when i run netscape) and I will get different behavior depending on which application I run. so reguardless of which way I like this pref, I will eventually be confused. ah well, as always do what you like.
Timeless, netscape 6 and mozilla are different applications. deal with it.
So anyways... Ducarroz, what do you say about logging the Netscape thing as a bugscape bug (since it doesn't affect us anyway) and let me checkin the Mozilla fix?
Sorry but I will not let you checkin the mozilla fix before we checked in the Netscape one. So far most of the people are very please with this dialog even if it's not yet finish. Therefore I will not accept to make them unhappy, event just for a while. If you cannot wait, just edit manually your own pref.
Since when is Mozilla development dependant on what Netscape developers have checked into their own tree? Mozilla development should continue regardless of Netscape. It's Netscape's job to look out for Netscape. It's Mozilla's, and the developers of Mozilla, job to look out for Mozilla. This is Bugzilla. This is a Mozilla bug. Why can't hwaara check his fix in? I don't think his intention has ever been to fix Netscape bugs (or wait for Netscape bugs to be fixed), nor is it his responsibility.
r=Hurricane on the patch
STOP, STOP, STOP. This is not a bug. This is about a feature that just couple of people don't like. I don't think it's a good enough reason to shut it down right away. I am the module owner, what ever if I am working for Mozilla or Netscape (technically, I am working for both), and I said NOT YET, IT'S NOT THE RIGHT TIME TO CHECK THIS IN. Just in case you have forgotten (http://www.mozilla.org/hacking/reviewers.html): mozilla.org requires module owner and peer review before code is checked into the mozilla.org CVS repositiory
I agree with JF. This is not merely an issue of whether it is a netscape dependant bug or not -rather it is whether people like the progress dialog or not. After a lot of initial discussion (maybe over two years) it was decided to implement the progress dialog. It would make more sense to implement a "Dont show this again" checkbox in the progress dialog rather than just get rid of it. The decision to checkin the changed pref should be not be taken ( in my opinion as a "Mozilla developer" who incidentally works for netscape) just because someone has the patch. Being outside the Netscape firewall doesnt give any mozilla developer privileges to check in stuff into the tree just like it shouldnt for those inside -It has to go thru the proper channel i.e. through the module owner and the review process.. This issue should be taken out to the newsgroups and we should see if it is a popular feature or an annoying one.
Just wanted to say that I totally respect your authority here, ducarroz, don't worry about that. So let's discuss this; A lot of users (including myself, hence the offer to fix it) have all noted that this dialog is useless and shouldn't be. The decision is simple - why have a useless dialog? Useless things tend to be referred to as "bloat", and we don't want that. At least not in the Mozilla tree. right? Initially, we wanted it removed - but Seth commented that we can just disable the pref for Mozilla and have it enabled for Netscape since we (seems like it's users vs. Netscape here?) disagree. Ok, so my patch fixes this for Mozilla but not for Netscape - since I am not a Netscape employee and thus do not have access to the commercial cvs. Ducarroz, let me just ask why the Netscape-specific issue is hindering me from fixing it in Mozilla? You noted that "if you can't wait..." well - given that the tree closes in about 7 hours for 0.9.2 trunk freeze - I can't wait. Because I know that you NS engineers will be working on other things and not be available for review then (coincidence?). Read the bug from its beginning. Read the thread some people started about this (unaware of this bug, FYI) and you will see that the general concensus is to remove this dialog. There is no doubt about that. So the question remains, Ducarroz, you are the module owner -- and I respect that -- but just because you like the feature and some other people don't doesn't give you the right to stall this bug's process.
backing up a little bit, Jean-Francois said: ------- Additional Comments From Jean-Francois Ducarroz 2001-06-19 15:51 ------- Sorry but I will not let you checkin the mozilla fix before we checked in the Netscape one. ------- This is wrong. A module owner cannot withhold review of code because something has not been implemented in the commercial tree. A module owner can say that the code is wrong after reviewing it and explain the technical flaw to the patch's owner. He could also explain why the code is bad for the module but he cannot withhold review because of some commercial concern. Doing so is inappropriate.
backing up a little bit, Håkan Waara said: "A lot of users (including myself, hence the offer to fix it) have all noted that this dialog is useless and shouldn't be" "you will see that the general concensus is to remove this dialog. There is no doubt about that." ------------------------------------------------------------------------------ The first statement is illogical in the light of the arguments which were presented in previous comments - we have not arrived at the decision to implement the progress dialog because JF had time on his hands - it was done because it was a desired feature to have in a "MAIL PRODUCT" not a netscape product. The second statement is a non sequitur in that it was obvious from the previous statements that the best place to discuss this issue or to obtain general concensus would be in a mail newsgroup and not in a bug. Infering that these few opinions comprise those of the mozilla community is ridiculous and presumptuous.
I thought I heard, above, that this dialog will have a cancel button in it. A cancel button that will cancel the send, not just dismiss the dialog. That's not useless. I personally support Jean-Francois in this. Let's wait till the feature is complete before we start evaluating on the basis that it is. Also, I think the tone in this bug is a little aggressive. Do you guys think people will be more or less receptive if you make harsh comments. The big win is if we build a good product. Personal wins mean nothing in this endeavor, if they are not on that path. It's a lot easier to cooperate when everybody is really listening to each other. And it's a lot easier to do that when you don't immediately go to guns :-)
Sorry but I cannot approve somebody to check in a fix in the tree that will cause a regression event if this affect only Netscape. That why I said first we need to change the Netscape side (to avoid the regression) and then checkin the modification into the Mozilla tree. We have couple of issue to solve here: 1) totally disable the progress dialog for Mozilla users is maybe not the best thing to do. Varada has proposed to add a checkbox "don't show me anymore". 2) This dialog will have very soon a cancel button. It was already there but not fully functionnal therefore we decided to disable it for now. Once the cancel button back, that will be the only way to cancel a send progress. If we are not showing this dialog for Mozilla user, they will use an important feature! 3) At this stage of development, it take time for getting a fix into the Netscape tree, I have to go through the whole PDT process. If we really want to check in the current proposed fix, we should rather wait that either Netscape checked in its side of the "fix" or that Netscape Branch. Else, we will have a smoke test blocker bug the next day that will keep the tree close for every body. That's not the best way to work together. I don't understand why people are so in a hurry to change something like this (especially when there is a work around) while we have so much other stuff way more important to fix first.
I apologize for any aggressive tones that I might have projected in my earlier comments. It is merely that we have far worse bugs that we can work on and help fix and right now that will assist us more towards building a better product.
This bug is long so I just skimmed it so I apologize if I'm repeating something that's been said a zillion times. We already have a patch to turn on smtp progress. Once that's on we can add the cancel button back in. As ducarroz mentions, it was taken out because it didn't always work and we didn't think it was good to give a false sense of security. I hope that both smtp progress and turning back on cancel will happen. Netscape 6.x got a lot of feedback about how having the compose window disappear before a send was finished was confusing users. Most of us liked the other way because it appeared faster. But users liked the sense of security more than the speed. We also found that people weren't looking at the status bar for send progress. This dialog that comes up in 4.x made people feel that they knew when their mail was being sent. I think that's a really good thing. Once we get smtp progress and the cancel button back in, it will be even better. So, as a member of Mozilla, I think turning the dialog off is bad for mozilla (until I get user feedback to tell me otherwise), and vote to keep this on.
Ok, let me re-iterate the reasons for why I don't think we should have this window: 1. It provides no function that cannot be logically added to the already existing msgcompose window a) We could have the msgcompose window open till the msg is sent b) We could have the stop button in the toolbar do what you propose this "Cancel" button should do c) The statusbar's progressbar could be used instead of the dialog's - assuming that we will actually display something else than the "undetermined" state. We can also write descriptive text about what the computer is doing in the statusbar when sending a msg. 2. It causes a bunch of other problems related to closing this window and immediately closing the msgcompose window. As long as we keep the msgcompose window open till the msg is sent, the user will still have that sense of security.
SUMMARY OF ISSUES: 1. The extra sending message window bothers some people because it *clutters screen space* and provides *no additional information* or functionality. 2. Some other people like it because it give *security about the send process*. SOLUTION: Both goals (send confirmation and no clutter) can be achieved by the suggestions made by Håkan Waara 2001-06-19 23:37 and Peter Lairo 2001-06-19 13:06 1. keep compose window open *until* send is complete 2. add a *stop button* to the compose window (maybe it would only appear during send) 3a. pop up a dialogue *after* send with send status (success/failure) 3b. play a *sound*: "Message was sent" 4. provide sending status in *status bar* (assembling msg, sending attachment1 [details] [diff] [review], ..., message send complete. These solutions will do the job that is required *even better* than an extra window and satisfy ALL of our concerns. PS. I (experienced user) am confused about what happens when I click on the "x" (close) of the extra window versus the "x" on the message itself. One cancels the send, the other cancels and discards the message - inconsistent and confusing. PPS. the N6.01 feedback seems to be a result of the compose window closing *before* the send is complete. This would no longer be an issue with the above recommended solution.
*** Bug 86884 has been marked as a duplicate of this bug. ***
CCing myself. Sometimes an RFE (i just duped my own bug below) is so necessary that we need to call them "bugs" because right now that mail sending windows is really stupid and not useful. A bar exactly like the one on the browser (that shows progress) , maybe with a % display inside it, and a brief explanation of what it is doing (sending message x of n) should be a great improvement in UI Sure, like i really enjoy sending a 5mb attachment and monitoring my ethernet/ppp interface to see how much bytes have been uploaded since i turned on the application so i can have an idea of how much is left to send! Developers should really take time to implement this, maybe a good feature for 0.9.3 or up
Am I missing something? Kevin Murray's 2001-06-19 suggestion that the progress window be off by default for Mozilla and on by default for Netscape came completely out of the blue, with no reasoning or justification at all. Yet it seems to have been accepted implicitly by everyone here, both inside and outside Netscape. But I can't see why this should be the case. If something is useful feedback for Netscape users it is useful feedback for users of other Mozilla distributions, and vice versa. I mean, it's not as if Netscape in particular need this otherwise-unnecessary window because they're going to show advertisements in it or something, are they? (`Message being sent too slowly? Click here and upgrade to FooBar DSL now!') A few brief points on the UI itself: (1) Adding new secondary windows should be the last resort for solving UI problems, not the first resort, and it reflects poorly on the mail/news team that they persist in relying on it. As Peter and Håkan suggested, providing obvious send feedback in the message composition window itself is trivial: disable all the controls in the window except for the status bar and the `Stop' button, then show send progress in the status bar. That is, do exactly what Mozilla 3.x for Unix did. (2) Having a UI pref to turn off the progress window is a non-starter. If people were annoyed enough to want to turn it off, by the time they reached the skill/knowledge level required to toggle the pref they would have long since switched to another mail program. (3) The progress window is not a dialog. Dialogs are modal, they get information from the user, and they don't go away until you click a button. Progress windows are non-modal, they don't take any input from the user (other than a `Stop' button), and they go away all by themselves. Because of that: (a) You can't use a progress window for sending a message if you leave the composition window open at all, because the progress window is non-modal so you can apparently go back and fiddle around with the message while it is being sent. (b) You can't add a `don't show me anymore' checkbox; because it's unreasonable to expect the user to swat at a checkbox, in a window which is going to disappear any millisecond now, if they don't want such windows to appear in the future.
Yes, i share your opinion. I think the idea of disabling/enabling this is just wrong. It's just a cheap workaround to hide a nasty decision of UI Let's use the code we already have from other versions to implement a good mail bar that does what we have already discussed for so long
I vote to keep the dialog as it provides a clear indication of what the application is doing with my message. I don't typically associate the message compose window as one with a progressmeter in its statusbar. Furthermore, providing all the disabling is a valid suggestion (bugs should be filed) but I contest that providing it all is "trivial." I also agree that the dialog should have a cancel button. While I'm here, I'll also point out that the dialog is not modal, merely dependant, which means I can edit the text in the message while it's sending. Is this valid/defined? Shouldn't the dialog be modal?
The dialog should be modal to the compose window (Application Modal?) but should not block the user to do something else while sending a message.
If the download/sending message progress bar in the status bar had a *color* that (strongly) *contrasted with the theme's background color* (e.g. green, dark blue, even red), then people would notice it and actually be able to use it. (BTW, I'm using the modern3 theme). This would be more than adequate for providing the required level of feedback. Another useful improvement would be to move the descriptor text ("sending message", "downloading", etc.) closer to the progress bar. Currently, the text is on the far left and the bar is on the far righ of the status bar - this is poor UI. In no case do we need a superfluous extra window to compensate for *lack of minor UI tweaks*.
Ben, what is the sole purpose of a statusbar, if people wants to see a dialog in addition to it? Why have two places where we display the exact same (progress) information? People seems to say "I want this dialog because it keeps me informed of what is happening..." - why can't we do this in the statusbar? If we provided some more useful text entries to display as status text in the statusbar, people would notice - and you'd get that without adding any annoying colors.
*** Bug 86884 has been marked as a duplicate of this bug. ***
You will be familiar with this screenshot Let's not reinvent the wheel Netscape 4.7x's window is what we need IMHO Can we do a little voting to move along?
The screenshot Francisco attached is somewhat what I had in mind too.
If you're going to do it that way you need to disable the editable fields (actually it sounds like we need to do this either way). I'd almost suggest changing the mailview to show how the message would look if the user received it. There are advantages of the dialog over the window, one is that people can set their mouse to snapto the button which means it's very obvious how to cancel the message delivery. As I look at that picture nothing draws my attention to the stop button, I wouldn't even guess that it's particularly important. It would almost be better if we put a cancel send button up to replace the send button. Look at the window, of the toolbar items (10) only 1 should be available, 4 appear available. We already noted that you shouldn't be able to make changes to the message (3 edit controls that look editable). Yes I know this is the nc4unix messenger window slightly hacked, but it was made as a suggestion. Most likely we wouldn't want anyone to select a menu item in most cases it would have undefined behavior. If I were designing a macosx mail application (bear with me, I haven't used macosx mail :( ) I would use a sheet to drop down a cancel button. I'm guessing that while the sheet is displayed, i could still update the status line and throbber. Anyways I'll try to get a picture of what macosx's mail app actually does since it's probably a good thing to see. (I'll try to get one from beos too, but that requires a reboot).
Okay, I'm not sure what OSX sheets are, and I know many people don't like changing UI elements around, but maybe something good will become of the following suggestion... How about changing the appearance of the entire message window to be more results-feedback oriented, sort of making it a hybrid after the "send" button is hit. A) Place the progress and cancel buttons in a more prominent location B) Replace the rest of the window with a "preview" view See the following attachment. This is not an additional window, but the message window would rather become this window when send is hit. (I know mpt will have a problem with this :) )
Ben's attachment does exactly the same as the one i showed I think it's not possible for the protocol to show progress of individual sending of attachments (the protocol sees attachments as part of a message) so it would rather show sending message 3 of 6... or something similar So what's the problem? I still think this debate should have ended lots of time ago. Netscape 4.7x's mail client shows the info the user wants to see, and netscape/mozilla developers are familiar with the code
http://developer.apple.com/techpubs/macosx/SystemOverview/AquaHIGuidelines/Aqua HIGuidelines.pdf Figure 6-1 'Document-Modal Dialogs (Sheets)' just in case people are curious about osx's ideas. ben's design actually reminds me a lot of sheets. A quick look tells me that i do like seeing the message preview form instead of the message compose form, that does solve the problems which were brought up as side issues. But i'm not sure I like the sending progress bits, the whole arguement over not having a dialog was to use the window's progress meter (and status line) instead. But clearly we have all of this useless space in the window where the sheet like element was stuck. -- It's really like apple was thinking about the problems we're dealing w/ here. -- I need to get my hands on an osx capable mac :-(. to francisco: The protocol does know what percentage of the data has been sent, and since it's a linear thing we could guess which attachment is being sent. This might actually be useful if someone realizes that they are trying to send a huge attachment ... It'd also be nice if we could tell the user how long we think it will take to send the message. Currently i'm still in favor of the dialog over the pseudo sheet, but I definitely like the message preview change.
QA Contact: esther → sheelar
Blocks: 90485
Obviously, we currently have two windows (msg compose and send progress) that duplicate some functionality. Have we already decides *which* windows needs to go away? It may be reasonable if the "send" button would just *replace* the compose window with the send progress window. This has several advantages: - No need to disable the edit controls (since the window is gone). - No danger that the user will not notice the progress meter (since it's the only thing we are showing) - It gives a clear indication of what's going on - we are no longer composing a message (the compose window is gone), we are sending it (the progress meter is right in front of us). P.S. No matter what we do, we need to make sure we do not fire the progress bar/window/etc too early. Currently, it is fired *before* we check that the message has the rigth charset. And if it turns out that it does not and the charset warning message pops up, the progress window is already there! And if I chose to change the charset, the progress window is still there. And when I press "Send" after changing the charset, I get the *second* progress window.
Aleksey: If the progress window stays and the compose winddow goes, we must have a way of re-creating the compose window in case of a transmission timeout or user cancellation. Otherwise the message will be lost, which certainly is not the correct outcome.
As near as I can tell we can already do that. If something fails to send when you are sending, say, unsent messages it will re-create the compose window.
This bug is about loosing the progress window. It makes a lot more sense to keep the compose window and show the progress there since the user is much more comfortable seeing his text intact until the send is complete. Also, if the user fires off several messages (or even just one) he will have more info on the status of each send because he sees the text, addressees, subject, etc; whereas the progress windows show limited information at best. When I send a message, I want to see the *message* being sent and not have it go into nirvana and be replaced with some *disjointed progress window* which doesn't make me feel comfortable about the well-being of my laboriously created message.
I disagree. Personally, I would rather see the compose window go away and the dialog with sending progress stay. If that could happen I would be more than happy.
There are several good reasons for why this window shouldn't have been commited to CVS in the first place: CONSISTENCY * All other major windows in Mozilla currently do not do this. They provide a statusbar at the bottom of the window, tracking the progress of whatever the operation is. TIME * The time it takes for a message to get sent may vary. According to studies I've read (most noticably from Jakob Nielsen's www.useit.com) most users still use slow connections. Therefore it's of extra high importancy that we persist whatever information the user is "going away from" as long as possible. For example, a couple of weeks ago a patch was checked in so that you could still scroll/select text/use a webpage when waiting for another to load. Note that before, we had thrown away the page, in favor of loading the new one. This is the exact same thing as putting up a new progress window, it just throws away the email while displaying a redundant window, which could easily be integrated with the compose window. RE-READING Many times when I send messages, while I wait for the message to be sent, I briefly re-read it. Sometimes, I discover that I forgot to add an attachment to the email (see bug 35601) and then the stop button, sometimes I discover a typo, and so on... A good email client would let me do this, while giving me the option to stop the send process directly from the window. Possibly by switching the "Send" button over to a "Stop" button and disable all other buttons, when the send is taking place. REDUNDANCY / CONSISTENCY Let's look at it: what's the advantages of this progress window over a slightly extended and fully usable compose window? Nothing, as far as I can see. With a compose window that would be consistent with the navigator (Stop button in the toolbar and a statusbar) this window would never have to exist. In response to blizzard and Aleksey: having a window hide/show like you suggest contributes to an unstable UI. Here would having a compose window open with a progressbar in the statusbar also solve the problem. It's embarassing that this window even made it into the default prefs, how can that be? Jglick, what's your take here? Thanks for listening.
This progress window isn't going away any time soon. New functionality will be added to it, such as cancel and possibly an ability to return to the compose window upon finishing the send. I'm happy to keep this bug open for discussion with the understanding that there's no plan to change the current behavior. Or we could mark it wontfix to reflect the true state of the bug. Either way is fine.
>CONSISTENCY >* All other major windows in Mozilla currently do not do this. They provide a >statusbar at the bottom of the window, tracking the progress of whatever the >operation is. The compose window is not a window like any other Mozilla window. It's the only one which send data instead of receiving it. Users (especially not power users) need more feedback than just a simple progress bar! BTW, I'll soon reactivate the cancel button in the progress window, I have this working in my tree...
How do you guys feel about closing the compose window before opening the sending progress dialog?
This is frustrating, I ask questions but get no good answer. Putterman, your response was basically that this discussion is meaningless because you have already decided otherwise. Therefore, I am asking a simple question to you: What is the reason to have this window, when all of the functionality (progressbar, cancel, status text) can be integrated in a much slicker way with the current compose window?
>How do you guys feel about closing the compose window before opening the sending >progress dialog? We use to hide the compose window during the send but the feedback we get was that the user did not feel confident about it. The UI/usability team has therefore requested that we keep the compose window open and show a progres dialog like in 4.x (window). It's really important for the user to see that the message is beeing sent, they need and requested it! Sure power user might be frustated by this extra level of information but you can still disable the the progress dialog.
I expect to get negative feedback about my next few statements, but what the heck. This is an example of a type of bug that I find annoying. Something gets checked in and a bug gets immediately created to back it out. There are also a lot of bugs that get bogged down in discussion and no decision gets made. Sometimes I'm the one dong the bogging down and sometimes I'm the recipient of it. Regardless, someone needs to make a decision about the UI. Jennifer makes the final UI decisions and Seth makes the final UI engineering decisions for mail. Decisions have been made and I say let's stick with them and move on. Debate is fine but at some point I'd rather see people working on something where they can be more productive. end of comments I expect to be taken negatively :) To answer hwaara's question, after Netscape 6.0 shipped we received a lot of feedback about having the compose window disappear and not have a progress dialog. People missed the NS 4.x behavior. We never tried having the window disappear and having the dialog stay up. In the discussions of that people thought that might look strange, but as I say we did not try it out or really design it. That might work better if we get the checkbox back in the progress dialog to have the compose window return after send. I haven't seen any negative feedback, besides in the bug, about the progress dialog yet. If we get reports of lots of users thinking this is awful then of course other solutions will be explored. What I do know is that we got reports in NS 6 of people asking for this behavior. Until I get other data that this is a bad experience for users, I don't see the need to change it.
marking wontfix. we've got a spec & design (from jglick) and an implementation (from ducarroz) that the mozilla mailnews module owners (mscott, bienvenu, sspitzer) are pleased with. there's a pref to disable the "sending message" window. if you don't like it, use that pref to turn it off. feel free to continue the discussion in this bug. but we aren't going to remove it. if there are other issues (like blizzard's comments about how the two dialogs interact or behave "I would rather see the compose window go away and the dialog with sending progress stay"), let's open new bugs on that.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WONTFIX
>there's a pref to disable the "sending message" window. Is there a UI for this?
no UI for the pref. The only problem with not showing the progress dialog is that you would not be able to cancel the send!
I protest this bug being closed as wontfix. The extra window is being shoved down our throats despite some VERY persuasive arguments to get rid of it (e.g., (mpt) 2001-06-20 12:39; Håkan Waara 2001-07-27 + screenshots with very good solutions). It is clearly *poor UI* to have *two windows displaying what one could easily do*. The only reason that was stated to have the extra (superfluous) window was that some former NC4.x users requested it because the current compose screen doesn't *yet* show the progress and status prominently enough. So instead of using a poor UI solution because it is easier, it suggest we do it right and *show the progress more prominently in the compose window* where people can see their message AND the send status. This is where our efforts should focus on - "To boldly go where no-one has gone before" ;) PS. What is the pref (which lacks UI) to turn off this #$&*§ window?
This bug should serve as a good example of what happens if you add major features before asking the rest of the Mozilla community for feedback. I'll shut up right about now and work on something useful.
Check out http://www.mozilla.org/mailnews/specs/meetings/Notes_1_9_01.html. This was originally proposed around 1/9. It was mentioned in a status report which had a link posted in it on 1/8 in a message I sent to n.p.m.mail-news. This didn't go in until June. So there was time to argue about this. That said, not every decision, UI or other needs to have agreement from the community to get in. If it did, then nothing would ever get done. That's why there are module owners such as Seth and Jennifer who get to make the decisions. This is not a democracy where everyone gets to vote on what the UI looks like and the majority wins. Everyone can participate in the discussion but the module owners make the final call.
As I mentioned 6-18, adding the progress dialog was directly in response to feedback we got from the first release. Several bugs were filed and people commented that they lacked confidence that their message was actually sent and that they wanted more feedback. We also got a lot of negative feedback when the Compose window disappeared and then reappeared suddenly when there was a problem with the send operation. These same concerns were also found when had usability testing done right after the first release. We've also learned that for some reason, user do not look in the status bar. I don't know why, they just seem to completely ignore it. The pros and cons of different implementations were discussed in the proposal doc, http://www.mozilla.org/mailnews/specs/proposals/SendingMail.html. Given this data, we thought that the 4.x solution, the progress dialog and leaving the compose window open, was reasonable. Maybe we could let Jean-Francois finish implementing this feature completely before rejecting it?
I've filed a bug 92625 on the problem I've described in the PS of my comment from 2001-07-27 08:07. I also want to add that I completely agree with Peter Lairo's last comment - while there were good arguments against some of the proposed solutions, so far nobody explained while "Sending Message" has to be a separate window, instead of being a part of the message composition window. As jglick explained, the status bar is not visible enough, but we can put a progress indicator it in a more visible part of the window (along the lines of attachment 39594 [details]). *Is there any good reason not to do it this way?*
Obviously, I'll accept the module owner's decision, even though I think it was a very bad one in this case. I hope they will rethink it. putterman: OK, it may have been discussed, but not all of us know all the time where some spec or discussion thread is going to pop up (I didn't notice the discussion and, as an outside observer, I am quite active here). The conclusion of a limited discussion should not always be the final basis of a spect. If good arguments are made (as they were here) then an already decided spec should be reconsidered. It's the "truth over process" principle - I just made it up, OK ;)
verifying wontfix. let's stop beating this dead horse.
Status: RESOLVED → VERIFIED
> let's stop beating this dead horse. Yesss Maahsta (but why did this horse have to be killed in the first place?) PS. Is it allowed to "verify" one's own decisions (wontfix)? Shouldn't that be done by a second person to "verify" that the first didn't screw up? Just curious, because many poor decisions seem to be resolved AND verified by just one person.
It is definitely not allowed. At least by good practice. And actually logic: if the same person can verify, verifying is unnecessary.
> We've also learned that for some reason, user do not look in the status bar. I > don't know why, they just seem to completely ignore it. Jennifer, allow me to enlighten you on that one: the problem there was that Netscape 6.0 defaulted to the Modern 2 theme, rather than Classic. Compare the contrast (or lack thereof) between idle state and determinate progress in the status bar in Modern 2 and Classic, and you'll see what I mean. (Modern 3 isn't quite as bad in that respect, but it's still pretty poor.)
>> We've also learned that for some reason, user do not look in the status bar. I >> don't know why, they just seem to completely ignore it. > Jennifer, allow me to enlighten you on that one: the problem there was that > Netscape 6.0 defaulted to the Modern 2 theme, rather than Classic. Compare the > contrast (or lack thereof) between idle state and determinate progress in the > status bar in Modern 2 and Classic, and you'll see what I mean. On Windows Classic, the progress bar is dark grey on a light grey background, which I think is actually less noticeable than Modern 2.
*** Bug 94600 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: