Mail Blast UI : GSoC Midterm Report

Interesting that you and I had the same idea about axing the old "advmultiselect" group selector. Are you using select2 for that? (if not you probably should rather than introducing another plugin with the same functionality since we ship select2 with core).

See https://github.com/civicrm/civicrm-core/pull/3673

I'm not sure if you have ever used the SMS feature in CiviCRM but it's an embarrassing fact that all of the mass-SMS code was copy-pasted from the mass-mail code -- it's a maintenance nightmare. If you still have time to work on this (and it sounds like you do since you are at half-time and so far along already) I strongly encourage you to make sure your code is abstract and reusable (this may require some rewrites but will be well worth it!) and then plug the SMS code in to use this new UI, getting rid of all that copy-paste boondoggle.

This looks great, and I really like the interface of selecting groups.  (I get irritated by the "advanced" multi-select).

One important thing to test will be what happens when you have a well-used site with a hundred groups and hundreds of past mailings.  That's a lot of things to pull, and then to have them show up twice (include and exclude), even a reasonable search will be cumbersome.

Also, the + and X aren't 100% clear unless you have the benefit of knowing that you can both include and exclude folks.  One might reasonably think that the X is to remove the group from the box of selected groups.

I wonder if making it two separate select2 fields would actually make it simpler: one for groups and mailings to include, and one for those to exclude.

Going back to the person who's been using CiviCRM for years: it'll be important that there be no limit on the number of suggested matches.  Organizations who use CiviCRM for years may have several dozen past mailings named "year-end appeal" with all the combinations of segments, follow-ups, and years:

• year-end appeal 2013 mid donor
• year-end appeal 2013 small donor
• year-end appeal 2013 lybunt
• year-end appeal 2013 event attendee
• year-end appeal 2013 newsletter/other
• year-end appeal 2013 mid donor followup
• ... and follow-ups for the other segments in 2013
• ... and the whole set for 2012, 2011, 2010, etc.

There's nothing you can do to stop this from being long, but it will just be an important factor to consider: assume that the list of past mailings is repetitive and a mile long.

These screen prints look so much better than the older mass mail screen layouts. I can't wait to use it.

One screen that I think is confusing for users is the area for "Mailing Recipients"

It is confusing to list groups to exclude in this section . I would add a new section to that screen labeled "Mailing Exclusions" or similar. (which should be collapsed by default as in my experience this is rarely used. )    The existing double icons each with an X is very confusing.

Thanks for all your work so far.

Why is the setting for "Online Publication" nested underneath the section for "Track and Respond"?  I think this is confusing as a typical end-user would not understand they need to click/expand "Track and Respond" in order to change the visibility.

Andrew totally agree with the suggestion that "making it two separate select2 fields would actually make it simpler: one for groups and mailings to include, and one for those to exclude."

It may seem 'tidier' to do this in one field, but it surely risks more mistake.

Having one field for INCLUDE and a separate one for EXCLUDE is way more obvious imo.

I also agree with the previous comments to keep the include/exclude options as separate fields. For a reasonably sized org, it would not be uncommon to have a hundred groups and hundreds of mailings. It's hard as it is to search through those -- we don't want to double the length unnecessarily.

A few other comments:

• I think you should reconsider how you've combined some of the existing steps into single steps -- combining track and respond with content, and preview/test with the schedule/send step. I think that's unnecessary, and loads those tabs up with too many options. Simply implementing the tabbed interface and retaining the existing steps should improve usability significantly, as the user is able to skip a tab if desired.
• There is an optional feature in CiviMail to use an advanced workflow. Enabling that option in the CiviMail Component Settings makes use of additional permissions to separate the create/schedule functions, and adds an approval step to the mailing wizard. Pertinent to this issue, you will need to accomodate the optional additional wizard step for approval, and as part of the workflow functionality, the schedule and approval pages are sometimes accessed as standalone pages (not part of a wizard, or in your case a tabbed interface). Just a heads up as that will need to be accounted for.
• I'm curious how you're handling the mailing recipients construction. In the current code, the list of recipients for a mailing is constructed when a person advances past that first page. If you save a mailing and return to it later, you're forced to begin at that first step, which consequently forces the reconstruction of the mailing list based on the selected groups/mailings. Basically, by forcing people through the wizard steps every time they edit a draft mailing, we are ensuring the recipients are rebuilt at the time the mailing is finally scheduled. But in a tabbed interface, it may not work quite like that, as a person could conceivably open a draft mailing and skip to a different tab without changing -- and thus without saving -- the mailing recipient step. I think this is an important issue to think through, as most people will expect the recipient list to be updated to reflect the contacts at the time the mailing is scheduled.
• On a related note, I assume that once the "submit mailing" button is clicked on the schedule tab, the mailing is no longer in draft mode and can no longer be modified via the tabbed interface. We may want to consider some UI changes to make that clearer.
• One other button-related suggestion -- we may want to alter the button names to be patterned after the contribution page UI. The buttons there are "save", "save and done", "save and next", "cancel". We don't really need a "previous" button since we're not strictly in a wizard structure any more. I think the above button model more clearly articulates the action being taken. Two subnotes -- the "save and done" could be misleading, as a person may think by clicking that the mailing will be triggered. We should throw a notification to inform them that the mailing will not be sent until it has been scheduled and submitted. Secondly, as per the last bullet, the "submit mailing" button will be different than the above pattern, and should probably standout in some way.