[imp] Problem sending mails when big attachments should be automatically linked

[Per olof Ljungmark]

On 2013-06-17 21:04, Michael M Slusarz wrote:
> Quoting Per olof Ljungmark <peo at intersonic.se>:
> 
>> On 2013-06-12 16:47, Anna Christina Naß wrote:
>>> Zitat von Enrico Scholz <enrico.scholz at sigma-chemnitz.de>:
>>>
>>> Hallo,
>>>
>>>>>> Are there any plans to (re-)integrate this feature, e.g. add it to
>>>>>> the drop-down menu of the attachment (which only says 'delete' at
>>>>>> the moment)?
>>>>> Absolutely not.
>>>> why not?
>>>
>>> Good question!
>>
>> +1
>>
>> Everyone here agrees that the old behavior was better.
> 
> This is a very incorrect statement.  The few people in this thread who
> have feelings on this disagree, but that doesn't mean the 99% of people
> using the software agree.
> 
> Allowing a user to select whether an attachment is "linked" horribly
> horribly fails what I call the "Mom test".  That test is essentially as
> follows: would my Mom be confused by the presence of this feature?  In
> this case, the answer is "hell yes".
> 
> A regular user is going to have very little/no idea the difference
> between "linking" an attachment and attaching the actual data.  More
> importantly, why would a user care which method they send with?  The
> question of overhead in this instance is an ADMIN question, not a USER
> question.  An admin is the one in the position to determine whether they
> a) want to allow hosting of attachments locally, or b) whether they want
> the overhead of sending large messages (and potentially dealing with the
> consequences when remote mail servers reject the message due to size
> limitations).
> 
> A user simple cares that the remote user can access the data they are
> sending.  I remain unconvinced that a normal user makes any distinction
> between the two.  And I remain unconvinced that this is worth the
> overhead to support for the few advanced users that *MIGHT* take
> advantage of this.  (An advanced user might want the option to change
> the MIME type of an outgoing attachment, for example.  This doesn't mean
> that it makes sense to actually implement and maintain though.  Feature
> creep is very dangerous.)
> 
> Not to mention that this feature is not important enough to add to the
> mobile view.  Attachments there must be handled by some admin defined
> default.
> 
> That being said, the "Mom test" is not an inflexible rule.  It can be
> worked around by hiding/moving advanced features to a location that
> doesn't confuse the normal user.  For example - we now allow some
> advanced attachment actions in dynamic view via a drop-down menu.  This
> drop-down won't confuse the "normal" user since they will just ignore,
> and the trigger graphic is small enough to be unobtrusive.  Compare this
> with the basic view method of putting giant form input boxes directly
> next to the attachment data.  (The basic compose view is a prime example
> of how NOT to design a useful UI for a normal user - it is tremendously
> confusing).
> 
> FYI: this confusion has been confirmed by at least one large service
> provider using IMP, where so many users were confused in the initial
> rollout with linked attachments that the feature had to be disabled.

Michael, your statement is absolutely valid in most scenarios, but the
definition of "normal user" is not static -

And, while on the "Mom test" subject, there are plenty of moms in the
receiving end that do not understand that there are links to download an
attachment at the end of a message unless you explicitly tell them, and
how many of your "normal users" will remeber to inform the recipient of
the procedure?

Here, the only outcome of this new "automatic" feature is that we have
to turn off linked attachments altogether which was not what I had hoped
for.

There are more reasons to choose one method or the other than size,
sometimes we *must* include the attachment with the message even if it
is large.

My $0.02

//per