Users feedback on what's a pain/missing on CiviMail

[xavier]

Hi all,

A few very valid points:

1) It isn't possible to add a handful of contacts to a mailing. What would you do if you want to send the newsletter to everyone in group X & Y, but wants also to send it to you your mother, that doesn't belong to X & Y but should receive it anyway ?

2) It's not possible to "forward/resent" easily. I sent the newsetter to X & Y, and then remembered I should have sent it to my mother. What would you do ?



As a workaround, I'd be tempted
1) to change the test so it doesn't insert the ugly "CiviMail test" in the sender & subject (would be an option triggered by a constant in the civicrm.settings, and send a "test" msg to my mother.
2) Provide a shortcut to 're-edit' a sent email (that's already possible already if you modify the url manually). Ideally, being able to skip directly to the test sending page (step 236 in the wizard, or so it feels .

> insert usual rant about how the wizard being such a bad UI for that compared to the wonderful tabs as for CiviEvent
>> insert dlobo usual answer about patches being welcome

What do you think about adding a param in the civicrm.settings.php to avoid modifying the sender & subject in the test mails (obviously, the default behaviour would stay like today, ie. adding the Civimail test) ?

X+

[xcf33]

We've been using CiviMail extensively including hacking the core to multithread each mailing so massive mailing size (we tested up to 200 k) can be blasted in short amount of time.

What I don't like about CiviMail are the following: (ranked by priority)

1. Bounce Handling:

The CiviMail bounce handling is not smart enough since it defines rules and looks for keywords in the reply mail and decide which email is bounced and which is not. This creates a discrepancy in the bounce (failure report) in our MTA vs CiviMail bounce numbers.

Suggestion: I think I will probably turn of the bounce processing in the future and use the MTA's API to synchronize bad emails in Civi

Moreover, the dreaded "Unknown bounce type" sometimes will put up to 70% or more of the mailing email on hold for obscure reasons. (PEAR timeout, etc) And sometimes those mails were actually sent out and the email addresses should not have been put on hold. The same is true for soft bounces, Civi will put soft bounce on hold as well but those email addresses are technically sound.

One suggestion for this is to set the default logic for unknown bounce type to not put on hold.

2. Reporting

Incidentally, the CiviMail reporting is not an actual CiviCRM report, the lack of ability to sort, filter and put bounced people into groups etc are frustrating. For our own specific use case we for example after we sent mail A, we would like to follow up with mail B to all the people who did not open mail A. This is impossible with the current mail report.

Suggestion: we have developed tools using the API to achieve this.

[xavier]

Suggestion: I think I will probably turn of the bounce processing in the future and use the MTA's API to synchronize bad emails in Civi

Regular MTAs (postfix, qmail...) don't have apis. And the format of the mail bounce depends of each server, and everyone has a different one, so no obvious way of spotting them.

Moreover, the dreaded "Unknown bounce type" sometimes will put up to 70% or more of the mailing email on hold for obscure reasons. (PEAR timeout, etc) And sometimes those mails were actually sent out and the email addresses should not have been put on hold. The same is true for soft bounces, Civi will put soft bounce on hold as well but those email addresses are technically sound.

Using mail() instead of smtp works better on that regard in my experience. Mostly because mail() returns a lot less errors than smtp.

One suggestion for this is to set the default logic for unknown bounce type to not put on hold.

+1

It would be very very useful as well to store the bounce email as an activity for the contact, so we can see what was the bounce reason (YMMV, but it often contains useful information eg. "you should now use xxx@yyy.com instead")

Incidentally, the CiviMail reporting is not an actual CiviCRM report, the lack of ability to sort, filter and put bounced people into groups etc are frustrating. For our own specific use case we for example after we sent mail A, we would like to follow up with mail B to all the people who did not open mail A. This is impossible with the current mail report.

Suggestion: we have developed tools using the API to achieve this.

Sounds great! Are they open source and published somewhere ?

X+

[sanook]

Would be great to be able to have a public newsletter archive...... 

[xavier]

Would be great to be able to have a public newsletter archive...... 

Indeed, but not great to the point of having someone dedicated resources to that, unfortunately

You might be the one making the difference ?
X+

[GinkgoFJG]

Would be great to be able to have a public newsletter archive...... 

I've put a little work into this, and I have some more changes I'd like to make but haven't had time to.  The changes that have been completed will appear in 3.3.  My patches improve the integration between CiviMail and Views, so if you're using Drupal, you should be able to create a public archive that way.

[bcobin]

Moreover, the dreaded "Unknown bounce type" sometimes will put up to 70% or more of the mailing email on hold for obscure reasons. (PEAR timeout, etc) And sometimes those mails were actually sent out and the email addresses should not have been put on hold. The same is true for soft bounces, Civi will put soft bounce on hold as well but those email addresses are technically sound.

One suggestion for this is to set the default logic for unknown bounce type to not put on hold.

I will add my voice most emphatically to the choir (solo?) here - the On Hold behavior means that you have to manually UnHold emails after each mailing. It's something that's super-embarrassing to try to explain to end users, so I'm put in the position of telling clients to give me a "heads up" whenever they intend to send an email, and then I need to keep track.

Overall, the whole mailing routine is very convoluted and confusing and, as it currently stands, could not really be left to the average end user. A few changes here would go a very long way...

[Donald Lobo]

Seems like having a CiviMail Make-It-Happen for 3.3.x / 4.0.x might be worth posting. If there are lots of small issues that we can fix as one make-it-happen proposal that would be great

anyone want to help figure out what are the features we can include and package as a community proposal

lobo

[xavier]

Started to braindump. Please to add/explain better.

http://wiki.civicrm.org/confluence/display/CRMDOC32/Improvements+on+CiviMail

Seems like having a CiviMail Make-It-Happen for 3.3.x / 4.0.x might be worth posting. If there are lots of small issues that we can fix as one make-it-happen proposal that would be great

[mcarson]

Incidentally, the CiviMail reporting is not an actual CiviCRM report, the lack of ability to sort, filter and put bounced people into groups etc are frustrating. For our own specific use case we for example after we sent mail A, we would like to follow up with mail B to all the people who did not open mail A. This is impossible with the current mail report.

Suggestion: we have developed tools using the API to achieve this.

+1
Although, some recipients would still get the follow-up email due to 'Email Clients' blocking some communications. My plan is also to use the API to achieve similar results.

[vidry]

Hi
Does anyone know if the newsletters archive system was implemented in the version 3.3 ?

Thanks

Would be great to be able to have a public newsletter archive...... 

I've put a little work into this, and I have some more changes I'd like to make but haven't had time to.  The changes that have been completed will appear in 3.3.  My patches improve the integration between CiviMail and Views, so if you're using Drupal, you should be able to create a public archive that way.

[Donald Lobo]

no, this did not get into the 3.3 release

any interest in playing the lead role on this so it could get into the 3.4 / 4.0 release?

lobo

[vidry]

Thanks for answering.
I don't think I will have time to go with that currently...

[xcf33]

Incidentally, the CiviMail reporting is not an actual CiviCRM report, the lack of ability to sort, filter and put bounced people into groups etc are frustrating. For our own specific use case we for example after we sent mail A, we would like to follow up with mail B to all the people who did not open mail A. This is impossible with the current mail report.

Suggestion: we have developed tools using the API to achieve this.

+1
Although, some recipients would still get the follow-up email due to 'Email Clients' blocking some communications. My plan is also to use the API to achieve similar results.

A bit of shameless self promotion but mail reports have been created as standard civicrm reports for civicrm 3.3

[mikeney]

I love CiviMail. It has been a true godsend for our small organization, hence a recent contribution.

From a design standpoint, I think a tabbed workflow instead of a linear one would be fantastic. Each time one returns to edit a draft mailing, we must go through all the initial steps of: Name Maling, Choose Groups, etc. Being able to arbitrarily jump-adjust-save between these pages would be a real time saver, especially for those of us running Civi on a host which is not lightning fast.

I am not a developer and don't know if this is even technical possible, just a thought.

Thanks to all!