Open Bug 35601 Opened 24 years ago Updated 2 years ago

Help prevent `oops, forgot the attachment! :-)' messages

Categories

(SeaMonkey :: MailNews: Composition, enhancement, P3)

Product:
SeaMonkey
Component:
MailNews: Composition
Type:
enhancement

Tracking

(Not tracked)

Milestone:
Future

People

(Reporter: mpt, Unassigned)

References

Details

Attachments

(1 file)

[Patch] Switches the place of the "Address" and "Attach" button
1.66 KB, patch
Details | Diff | Splinter Review 
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. :-)

Accepting
Status: NEW → ASSIGNED
Target Milestone: --- → M20
QA Contact: lchiang → pmock
Adding mail3 keyword.
Keywords: mail3
marking nsbeta1-
Keywords: nsbeta1-
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 fenella@netscape.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.
To Esther..
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: 23 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:

+---------+ +---------+
|   /""?/ | |    //)  |
| --'__/  | |   ///_  |
| --'     | |  (_/[3] |
|         | |         |
|  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
Keywords: ui
Product: MailNews → Browser
oops..reassigning too
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? :-)
Product: MailNews → Core
*** 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
Product: Core → MailNews Core
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.