Improve CampTix 'Notify' function, including adding auto-save and an Editor-style email composition

[ghost]

Imported from https://meta.trac.wordpress.org/ticket/3201 Created by @alicestill:

The existing Notify tool on CampTix (found in Tickets > Tools > Notify) is very useful for bulk contacting WordCamp attendees and subsets of attendees, but it isn't as user friendly as it could be.

Because Notify doesn't work as well as it could, organisers often have to send very small batches of emails using Gmail, or export attendee information into 3rd party apps like MailChimp. Note, organisers can't use Gmail for bulk emailing, as this results in Gmail either labelling emails as spam, or blocking all emails from a Gmail account for an undefined period of time (sometimes days).

Making the Notify tool more user friendly has the potential to save a huge amount of time across all WordCamps, plus remove the risks involved in exporting personal attendee data and prevent legitimate WordCamp email addresses from getting blacklisted by Gmail.

So I'd like to suggest the following Notify enhancements:

1. The ability to save and auto-save email drafts. Currently your email is irretrievable if you leave your draft. For example: if you accidentally close a tab or go back, there's no warning that you will lose your work, and it won't be auto-saved.
2. An easy to use, Editor-style email composition. Currently it isn't easy to compose an email without having a strong knowledge of HTML. Please see the attached screenshot of a portion of one email I composed for WordCamp Brighton. Everything needs to be coded in and there is no ability to drag and drop images - instead these need to be separately uploaded and then added using HTML. Images are vital in WordCamp emails as including sponsors in event emails is a criteria of most top tier sponsorship packages.
3. Ability to view sent emails. Currently, you can see an email has bee sent but cannot view the contents of that email or who it was sent to. Also, the ability to view and copy previous emails as templates would save emails needing to be created from scratch each time.

There's plenty of potential for further enhancements in future, but as a start, these changes would make a huge difference to Notify's usability.

[ghost]

Comment by @alicestill:

• Notify-email-screenshot.png added

Example of HTML needed for a basic email

[ghost]

Comment by @iandunn:

• Keywords set to Good First Bug Needs Patch

+1, these are great ideas.

2. An easy to use, Editor-style email composition

That would definitely be a better UX. We do need to be careful about including HTML in emails, since mail clients generally have very poor support for it, so it'd be easy to create something that is displayed wrong after its sent. We might want to prevent the div tag and any inline CSS.

That prevents a problem, though, if the preview doesn't match the final content. There might be an existing TinyMCE config value or plugin that allows us to limit the markup used on the client side, so that it matches the sanitation rules on the server side.

3. Ability to view sent emails.

This already exists for network admins, so it'd probably be very easy to allow it for site admins/editors too.

[ghost]

Comment by @Gabe462:

Thanks for posting this, alicestill!

Here are the requests I'm seeing in this ticket:

1. Save & auto-save drafts
2. Warning that you will lose your email draft if you close the tab or go back
3. An easy to use, Editor-style email composition
4. Ability to view sent emails

possible deliverables, in order of complexity:

1. add a javascript event that fires on page reload/close when there is content in the email fields
2. add a button to load an old message into the editor for viewing/resend
3. instantiate the visual editor for the "Message" field

Possible implementation:

1: add javascript to this page along the lines of window.onbeforeunload = function () { return "Are you sure?"; }

with exceptions for the send and preview buttons

2: Add a "load" link at the right of each email in the table. enable "show_in_rest" for the tix_email cpt for this page, and fetch the id corresponding to the email clicked. The title and content are written to the Subject and Message fields.

3: research necessary

[ghost]

Comment by @iandunn:

Replying to @Gabe462:

1: add javascript to this page along the lines of window.onbeforeunload = function () { return "Are you sure?"; }

That sounds good. It might help a bit to explicitly tell the user that there is unsaved content, in case they're confused about why they're being prompted.

2: Add a "load" link at the right of each email in the table. enable "show_in_rest" for the tix_email cpt for this page, and fetch the id corresponding to the email clicked. The title and content are written to the Subject and Message fields.

Hmmm, I'm not sure what a good way to do this would be. Ideally we'd want to reuse as much from Core as possible, since it already has this functionality built in.

Maybe this whole feature should be re-thought, since switching it from an admin page to use the regular CPT interface would give us the rich editor, auto-save, and viewing past emails, all for free. That could also be a big rabbit hole, and take longer than just adding things piecemeal, though.

We'd have to migrate the existing functionality into the CPT interface, but that might not be too much work. That might be worth exploring a bit, just to get a feel for what it'd take.

If it looks like it'll be a big project, then it might be worth holding off on it, since we've also discussed some plans to possibly migrate away from CampTix in the future. So, I'd suggest maybe playing around with it a little while, just to get a feel for how long it'd take, but don't get too deep into it. If it looks like it'll be relatively painless, then that might be a good option, but otherwise it's probably not where we want to be investing time at the moment.

[ghost]

Comment by @DJPaul:

I wrote an email system and APIs for BuddyPress that probably does at least half of this very well. To implement the other half of the features, it's probably pretty easy, and BuddyPress itself would arguably benefit from having those features added.

At the very least, there's a bunch of code that could be copied out relatively painlessly and re-used.

[ghost]

Comment by @alicestill:

I checked out the BuddyPress email system today and agree with Paul – it would be a massive improvement. Documentation here: [https://codex.buddypress.org/emails/]

It works much the same as adding posts, so would be easy for WordCamp organisers to pick up and use right away. It even comes with some nice extras, such as the ability to edit email colours. Integrating this existing system also addresses the potential HTML display issues Ian mentioned as it's already in use – and is proven to work – with emails that display nicely.

Very important to note that the BuddyPress system would need to be merged with Notify's existing ability to email subsections of attendees (i.e. the "Attendees matching any/all of the following" function). But this would be a handy addition to BuddyPress too, so it makes sense to work this function in. The BP system has 'Situations', which may not be needed for Camptix, or if they are, they'd likely need to be customised so they're relevant to WordCamps. Other than that, BuddyPress's email system would be an excellent replacement for Notify more or less as is.

I think it would be a big time saver for organisers, so would be enough to discourage exporting large amounts of attendee data to other third-party mailing systems.

Going forward it has the potential for further improvements, e.g. you could create a sponsors block; you could add the ability to email specific people, rather than subsets (reducing the need for Gmail); and you could add the ability to view emails online – among other things.

[ghost]

Comment by slackbot:

_This ticket was mentioned in Slack in #meta-wordcamp by missjwo. View the logs.

[ghost]

Comment by slackbot:

This ticket was mentioned in Slack in #meta-wordcamp by djpaul. View the logs.

[ghost]

Comment by slackbot:

_This ticket was mentioned in Slack in #meta-wordcamp by missjwo. View the logs.

[ghost]

Comment by @miss_jwo:

Hey all.

I am working with @DJPaul on this ticket. We have created a bunch of user stories to understand what the goals are be for the ticket. I'll update the ticket later with the restrictions/ requirements list from various reviews and UI wireframes as well.

---

Save/draft emails

In order to send emails As a WordCamp organiser I want to save and share drafts

Examples:

• Prevent data loss if you close your web browser
• Write and prepare emails in advance
• Share drafts between organisers for approval

Editor-style email composition

In order to write emails As a WordCamp organiser I want to compose an email without knowing HTML

Examples:

• Focus on writing content (organisers aren't developers)
• I want to drag-and-drop images into emails
• I want to be able to add my recipients' first name, last name, email address, and the ticket management URL, to the email.

View sent email history

In order to check what emails were sent As a WordCamp organiser I want to be see the email content and recipients

Examples:

• Organisers can check that other team members had sent an email

Customiser

In order to brand my emails As a WordCamp organiser I want to be able to customise the email header and footer

Examples:

• Add the conference colours and branding
• Add the conference logo
• Use a different font

???? "Red" questions (waiting for more info)

Use previous emails as templates

In order to save time when writing new emails As a WordCamp organiser I want to be able to copy/paste from previous email

Examples

• ????

[ghost]

Comment by slackbot:

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.

[ghost]

Comment by slackbot:

This ticket was mentioned in Slack in #meta-wordcamp by coreymckrill. View the logs.

[ghost]

Comment by slackbot:

_This ticket was mentioned in Slack in #community-team by missjwo. View the logs.

[ghost]

Comment by slackbot:

This ticket was mentioned in Slack in #meta-wordcamp by iandunn. View the logs.