Open Bug 35601 Opened 22 years ago Updated 1 year ago
Help prevent `oops, forgot the attachment! :-)' messages
Every day, all over the world, there are people who forget to attach the relevant files to their e-mail messages. When this happens the sender is made to feel silly, since they have to send another message to apologize for the previous one, and to include the missing attachments. Mozilla should do everything practical to prevent the user from feeling silly. And much of this problem could be solved with two simple changes to the message composition window. 1. Place the `Attach' button right next to the `Send' button. 2. Print the current number of attachments in small lettering at the bottom left corner of the `Attach' button.
I agree with this 100%, and have done this tons of times. It's annoying as hell; I'll write a nice email saying "download the attached file" and so forth, and nothing's attached because I forget. I'm not sure if the proposed changes go far enough to solving this problem (in the end, it's up to the user to remember), though they would help. updating summary
Summary: Help prevent `oops, forgot the attachment! :-)' messages → [RFE] Help prevent `oops, forgot the attachment! :-)' messages
[Already marked as an enhancement, in the Severity field.]
Summary: [RFE] Help prevent `oops, forgot the attachment! :-)' messages → Help prevent `oops, forgot the attachment! :-)' messages
Putting RFE right in the summary line helps the dev team to quickly identify enhancements from bugs. It's fine though if you don't want it there...
Ok, filed bug 36013 about allowing engineers to better identify RFEs without kludging up the summary line. :-)
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Adding mail3 keyword.
Maybe Mozilla could be really smart and look for the word "attach*" in the mail body. If there is nothing attached on sending, a dialog box could pop up and ask for confirmation.
Assign it to email@example.com
QA Contact: pmock → fenella
What's about non-english writers? should we start sniffing the body of a message for specific words in all humain languages? I don't think so!
Target Milestone: --- → Future
I didn't want to say that Mozilla has to know for sure whether the user wants to add an attachment or not. I'd rather see this as an additional help in case the user has used the word "attachment" or "attached". In German for example, the word "Attachment" is often used although it is an English word. I can imagine that German is not the only language that uses some English words concerning computer stuff. In other words, I think that looking for the English word should be enough.
QA Contact: fenella → esther
Nice idea, and the suggestions of mpt regarding the "Attach" button will already go a long a way into helping to avoid this, and at the same time, they make the implementation easier.
I have a patch that fixes #1. Coming up..
I don't understand what you mean by suggestion #2 mpt, please clarify. If it isn't too hard I can fix that too. Jglick: can you update the specs as appropriate for my fix? Thanks Does anyone have any other ideas, suggestions or concerns about this? Speak now, or stay silent forever :)
I am not sure that swaping those 2 buttons will really help! I am personnaly against changing position of UI element unless it really, really makes sense. Users won't be happy if we change the UI position at each release. We choose this order to match the one used by Netscape 4.x for which users are use to for several years now. Jennifer, any thought?
ducarroz: If you're against all this - why haven't you said so before?
Besides, ns4 doesn't have much to do with this bug. It's all about Mozilla
you get a point. But I haven't said go ahead! Sorry. Maybe The UI folk would love this idea, if it's the case I will accept to check this in.
I agree that forgetting to add the attachement is a something that everyone has encountered, but I don't think moving the Attach button over a space will make that much of a difference. If the goal is to the make Attachments more visible, we did that by adding the attachments field to the right of the addressing area. When attachements are added, they are listed in this field.
So I guess we can't know when the user wants to add an attachement or not. This is up to the user to remember, and we can do nothing about it. :( How does WONTFIX sound to you?
Find for me. Won't fix
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
I never said anything about telling whether the user wants to attach a file or not. That was Oliver's idea, not mine, and I agree that it wouldn't work. The main point of this bug is to add a decal, containing the number of attachments, to the `Attach' button -- something which everyone in this bug has carefully ignored. :-) Here's what it would look like (largely magnified), where you had made three attachments so far: +---------+ +---------+ | /""?/ | | //) | | --'__/ | | ///_ | | --' | | (_/ | | | | | | Send | | Attach | +---------+ +---------+ (Aside: The same number-in-a-box style could be used on a `Mail' button for showing the number of unread messages you had, and on a `Chat' button for showing the number of online buddies you had, on Navigator's toolbar.) Moving the `Attach' button next to the `Send' button is a secondary step, to make the number of attachments in the `Attachments' button more visible when the user is about to send the message. For *this* purpose, the Attachments pane is nearly in the worst place it could be, all the way on the other side of the window. I don't think the argument about changing the position of the buttons between Mozilla/4.x and Seamonkey holds any weight at all. There's only *one* button which is in the same position between the two versions, and that's the `Send' button. The `Address' button, the `Save' button, and -- yes -- the `Attach' button have already moved, so it's not like we're making anything worse.
I reopen the bug for reconsideration...
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Ok by me if you wanna give this a shot. Is #2 doable?
FWIW, Pine (my mail client of choice) puts a detailed list of attachments right next to the cursor when you hit send, clearly visible, and yet I still make the mistake. The reason for this is that the attachments message is positive reinforcement, but there is no reminder that one intended to send attachements in the negative case. Putting the "attach" button next to the "send" button might help, but since it would always be there it would not necessarily be enough, since people will eventually tune it out. I, unfortunately, do not have a solution to this problem.
I agree with Hixie. But it doesn't matter for me whether we check in the button-switching patch. I still think that this is either a wontfix or we should checkin my patch.
I think this is sufficent for mpt since we don't have an exact definition/spec on how we should go on. -> Browser, UI: Design Feedback
Component: Composition → User Interface: Design Feedback
Product: MailNews → Browser
Assignee: ducarroz → mpt
Status: REOPENED → NEW
QA Contact: esther → zach
*** Bug 106449 has been marked as a duplicate of this bug. ***
An additional idea would be to put more information on the sending message dialog. For example ----------------------------- Status: Sending 'Test message' Attachments: None [Progress bar] --------------- |Cancel button| --------------- ----------------------------- Sure, it would be a test of their reflexes to cancel in time, but it would probably catch a few mistakes.
I see nothing about comment 24 that I want to change. Please implement it, somebody. :-) --> Composition
Assignee: mpt → ducarroz
Component: User Interface Design → Composition
Product: Browser → MailNews
QA Contact: zach → esther
According to <http://home.dataparty.no/kristian/reviews/nextgen-mua/> KMail warns when trying to send an email that contains specific words, e.g. "attached" or "attachment" but does not have any attachments. A screenshot of the preferences window is available here: http://home.dataparty.no/kristian/reviews/nextgen-mua/kontact/detect-missing-attach Another solution instead of showing an alert box could be to display an alert icon in the attachment area when the user types one of the specified words for "attachment". If an attachment is added afterwards, the icon should go away.
(In reply to comment #34) > Another solution instead of showing an alert box could be to display an alert > icon in the attachment area when the user types one of the specified words for > "attachment". If an attachment is added afterwards, the icon should go away. I thought the same. Maybe the icon should be blinking too. As for the problem of supporting all languages, it would be enough to have a sort of dictionary file for every supported language and simply reading the right one according to the locale setting... And there might be an option to even warn with a dialog. OR, maybe this is the cleanest solution, an extension could be made for this..
*** Bug 238621 has been marked as a duplicate of this bug. ***
(In reply to comment #35) > (In reply to comment #34) > As for the problem of > supporting all languages, it would be enough to have a sort of dictionary file > for every supported language and simply reading the right one according to the > locale setting... A solution to the language problem that would be that: 1. There's a setting where you can list your own keywords. 2. The defaults for that list are contained in the localizations. 3. If people (like me) use one localization (English in my case) but wants attachment keywords from another locale (Swedish in my case), they can just edit that list. Also, it would be good if it was possible to match part of a word. Otherwise, for Swedish, I'd have to list something like... bifoga bifogar bifogas bifogade bifogad bifogat ... and probably a bunch of others as well. Anybody but me see a pattern here? :-)
*** Bug 319900 has been marked as a duplicate of this bug. ***
FWIW, my preferred method of ensuring people remember attachments is now to use Content-Type: multipart/mixed for all messages with attachments, and to embed them inline with the message text (whether it be plaintext or HTML). I think forgetting attachments happens largely because they are attached in a completely different part of the window from the part where you're talking about attaching them. Displaying them inline fixes this: you get used to embedding a file directly after the paragraph where you first mention it. This is much more natural and reliable than trying to sniff whether someone intended to attach a file, simplifies the composition window by abolishing the attachment pane, and (best of all) requires no confirmation alert.
I agree that showing attachments inline for the most part fix this problem. For example yesterday when I sent a few friends a photo, I could just drag it to the content of the message I wrote in Mail (Mac OS X) and it was displayed along with the text. Mail does not try to separate the message part with the attachments, and thus you do not forget attachments because they are a natural part of the message.
Assignee: ducarroz → nobody
QA Contact: esther → composition
I'm just checking in to take the other side. Apparently in 3.0b3 (maybe earlier) there is now code to look for words like "attachment" in the body of the message and put up an distracting dialog box if so. Imagine you're writing a message about attachment or attaching things (something that comes up a lot in my work communication) and every time you send a message you get interrupted by this useless message, because there was never any intention to "attach" a file. It is very annoying. Of course I see the purpose, but... things like this, where the software tries to get clever and guess intentions, need to be handled with a certain amount of humility, recognizing that it will never be clever enough, and so at a minimum please provide one of those "Never show me this again" checkboxes in the dialog so that users can easily turn them off. No doubt there's some way to do this via the settings hidden in the about: thing, but people shouldn't have to go there. Cleverness should never interfere with the work flow of people who haven't made the mistake you're trying to mitigate, especially when it is rare and of little consequence even when it happens. You should always give us the choice. My two yen...
Thunderbird has implemented help to prevent this in bug 244455/bug 498519, therefore moving this to be a SeaMonkey specific bug as it is no longer a core mailnews bug. (In reply to comment #41) > I'm just checking in to take the other side. Apparently in 3.0b3 (maybe > earlier) there is now code to look for words like "attachment" in the body of > the message and put up an distracting dialog box if so. Imagine you're writing > a message about attachment or attaching things (something that comes up a lot > in my work communication) and every time you send a message you get interrupted > by this useless message, because there was never any intention to "attach" a > file. It is very annoying. Bug 498519 changed this to be an inline message so that you're not prompted with a separate dialog. This will be included in Beta 4, so I would try that before getting too annoyed. In any case you can turn it off in preferences.
Component: Composition → MailNews: Composition
Product: MailNews Core → SeaMonkey
QA Contact: composition → mailnews-composition
Thanks for your note. I didn't realize there was a Preferences option for this, but after poking around for a while I found it. Thanks!
You need to log in before you can comment on or make changes to this bug.