[Tickets #10235] Re: Email attachments on printed emails

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10235
------------------------------------------------------------------------------
  Ticket             | 10235
  Updated By         | Jan Schneider <jan at horde.org>
  Summary            | Email attachments on printed emails
  Queue              | IMP
  Version            | 5.0.6
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2011-06-28 12:51) wrote:

>> Please don't simply revert while we're still discussing this. It's
>> not like this breaks anything.
>
> Not to sound like a jerk - but I had originally rejected this.  You  
> overruled that decision and committed this.  Reverting is entirely  
> appropriate. We need to stay at the status quo - only until we  
> decide whether we want should we add if necessary

True.

>> I don't buy your argument why we might include the basic headers but
>> not the attachment list.
>> 1) It's important, or at least useful, information about a message.
>> Not printing those anymore is a regression from IMP 4.
>
> I had a long discussion about this when we implemented the IFRAME  
> HTML rendering.  It really comes down to this:
>
> * You correctly render HTML parts.
> vs.
> * You can print the entire message.
>
> At this point, you MUST choose one or the other.  In the past, HTML  
> mails weren't as prevalent as they are today.  Not to mention are  
> rendering code and filtering code weren't all that great.
>
> But now, I would say that text/html has pretty much become the  
> defacto standard.  So viewing is more important than printing.
>
> Sometimes you have to make tough decisions.  Yes, it is a regression  
> with respect to printing messages.  But it is a vast leap forward in  
> the more common use case of viewing an HTML part.  So I stand by  
> this decision.

I think there is consensus about this descision.

>> 2) It's unobtrusive and won't affect many messages (probably depends
>> on how often you get messages with attachments. But then again, how
>> often do you actually print messages?)
>
> But going back to my original point: why is this attachment list  
> important?  How can it possibly be important to have an attachment  
> list when you are only printing (and caring about) a single part?

This question doesn't make sense to me. As you explained above we  
decided to print individual parts instead of the complete message for  
technical reasons. Thus the user doesn't even have a chance to print  
the complete message. Of course it would make more sense to only print  
the attachment list when printing the complete message, but that's not  
possible.

And to the original point: it's been requested by end users a few  
times, for whatever reasons. I don't print out emails at all, so I  
can't answer the question, but there seems to be a good reason for  
this. And to repeat myself: I don't see a huge difference to the basic  
headers that are *not* the headers of the MIME part either, but the  
headers of the complete message.

> When I print the portion of the message that contains the map to  
> Grandma's house, I don't care that she also attached pictures of the  
> cats that are going to be there to greet me when I arrive.  This is  
> worthless information, and cuts into the printable space available  
> on that first page.

Who are we to decide whether this is worthless information or not? If  
it's your concern that some users might not want this information to  
be printed with the message (I know it's not the message, but that's  
how users receive it), we can make it a preference. Just like adding  
the Printed By: header is configurable too.

>> I understand the technical limitations that still keep us from
>> printing all parts, and I don't have a smart solution for this. But
>> limitations of browsers should not keep us from providing us better
>> experience for the users. Actually the opposite, we need to provide
>> users with alternative solutions if something is limiting them.
>
> Possible solutions: print as PDF; popup print screens reload after  
> every printable part to load the next printable part while calling  
> window.print() on each one.

Printing all parts individually is a solution to printing complete  
messages (though a rather annoying one), but not to printing an  
attachment list.

PDF is interesting but a) requires a PDF reader to be installed, and  
b) doesn't work with HTML messages.

>> The crucial point is that currently the user is not able to print the
>> whole message if it consists of multiple parts. But they don't care
>> and will print messages anyway. In 95% (if not more) of the messages,
>> there will be one single printable message part. Users don't care if
>> they are looking at a multipart message. They are happy that their
>> message will be printed (and without even knowing about that, that
>> your worked around IFRAME printing browser bugs). They don't care
>> that it's only one part of the message, because that's probably the
>> only part they see inline anyway. Heck, the printout even has the
>> message headers, they won't even notice. All that's missing is,
>> gotcha, the attachments summary they had in their old version.
>
> These are all arguments for the creation of a feature to allow  
> printing of an entire message.  But NONE of these arguments are  
> applicable to what we currently have available: printing of a single  
> message part.
>
> We can't be mixing UI elements/features just because we are lacking  
> functionality.  I have spent a long time in IMP 5 to remove these  
> kind of decisions we made in the past - feature bloat if you will.   
> Instead we need to focus on the UI as CURRENTLY implemented (not how  
> we would LIKE it to be implemented).

I agree only partially. Printing messages (as few as sense it may make  
sense to us personally) is not feature bloat, but an important feature  
of a mail client.
Cleaning up features and tacked-on functionality is great, and you've  
done an awesome job at this with IMP 5. I can wholeheartedly  
understand that you don't want stuffed "hacked" into it again.

> As I have said multiple times in this ticket, having an attachment  
> list doesn't make any sense when you look at what this UI element is  
> intended to do: print a specific message part.  So this patch is not  
> appropriate.

I think this approach is too academic or technical, if you want to say  
so. It's correct, no question, but it's not how users are gonna see or  
use this feature. They want to print their message, they see the print  
icon (and in 95% of the message only one single icon), they click on  
it, and they complain to their administrators that the printout no  
longer contains the attachment list. *If* there are multiple parts and  
multiple print icons, they will figure out quickly that they have to  
print them individually. They will moan but work around it, like users  
always do. But they cannot get their freaking attachment list back.

I can't believe we spend so much time and energy on such a useless  
thing like printing messages. :-D I hope a single user is going to  
appreciate this.