[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         | Michael Slusarz <slusarz 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             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2011-06-22 16:16) 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

> 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.

> 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?   
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.

> 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.

> 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).

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.