easy-digital-downloads
easy-digital-downloads copied to clipboard
awesomemotive
Introduce EDD_Email_Settings API
EDD extensions introduce all kinds of different settings but one of the most common is some sort of new email message specific to the extension's needs. There are many extensions in existence now which introduce new email subject and message settings as well as a selection of email tags. Despite the end goal being pretty similar, there's quite a bit of inconsistency when it comes to how these settings are being included.
I propose that we introduce a simple new API for adding these specific types of settings. Here's a few benefits we'd gain if we did:
- Consistent location. Some extensions put their email settings under Downloads - > Settings - > Emails in a new subsection. Others include them under Downloads - > Extensions - > Extension name. Others like FES, Product Updates and Per Product Emails put them somewhere else entirely like they're special or something. I think all email related settings should end up under Emails (also discussed here).
- Consistent fields. Some emails include extra fields which others do not and the reasons are not always clear.
- More consistent tags. It isn't always clear to users why some tags are available for some emails but not for others. With a new API we might be able to make it much easier to maintain consistency and ensure all emails have whichever tags they need.
- Consistent UX. Again over here an improved UX is being considered. Enhancements like that could be really awesome and would be much easier to implement if we have everyone using the same method.
- Code simplicity. With a well constructed new class, extensions could register their new email settings in just a few lines instead of a few dozen lines (at best). They'll also likely end up getting more for free if we standardize a lot of common email settings.
Some extensions with email settings
- Frontend Submissions
- Simple Shipping
- Recurring Payments
- Software Licensing
- Commissions
- Reviews
- Custom Deliverables
- Message (planned feature)
- PDF Vouchers
- Per Product Emails
- Product Updates
- Check Payment Gateway
- Purchase Rewards
- Sales Recovery
- Wallet
- Subscriber Discounts for Easy Digital Downloads
Every single one of these extensions creates settings with at least a subject and message field as well as their own list of tags.
I think this change would make things easier for developers, make enhancements easier for us and most importantly, provide end users with a much simpler and more consistent experience.
I agree with this idea, though I'll point out a huge amount of the reason they're inconsistent and why tags aren't always available is because of this existing issue: https://github.com/easydigitaldownloads/easy-digital-downloads/issues/2151 where the email tag system that exists, for all intensive purposes, is pretty useless outside of of a payment context because the system is biased towards it. In plugins like FES and EDD Donations et. al., the existing email tag system can't be used because it requires the tags to be related to payments, so many of the extensions have had to implement their own tag system (often just placeholders with str_replaces).
Without solving that issue, I frankly don't think you'll be able to solve this one easily. If email tags could be easily and consistently used outside of a payment context, a lot of code from a lot of extensions could go, and most of those that couldn't standardize before could.
Also it's been discussed before about extensions like FES for example which have a lot of possible emails but don't necessarily need them to declutter. I'd point out, prior to FES 2.3, FES's settings system used Redux Framework, not the EDD settings panel, and as a result a fraction of the settings you see today existed because we were able to easily hide settings that didn't make sense based on the context.
A lot of these email settings could be removed with a simple interface that either lets users add emails from a predetermined either list or set of conditions, or frankly better yet, straight up conditional settings field support, which could allow the same functionality to be used across any settings type. This would allow EDD to hide a huge amount of settings if they aren't being used or don't make sense.
Thanks for the input @chriscct7! I agree. Tags could be improved and made easier to implement more consistently. Though I consider that aspect to be a smaller part of this issue's purpose. My real hope is that we can open the door to more creative and efficient solutions for email settings by abstracting them somehow with a flexible API.
In the short term I'd like to see all email settings become accessible in the same place (Downloads - > Settings - > Emails) and work basically in the same way. Down the road it would be awesome to explore better ways to manage all email notifications. Seems like this is the first step.
I think at minimum we need to get all email settings under the same home, where they belong in Emails. That would be a big step forward.
After that, adjusting the tag system to not be so biased towards payments would also be great. I can see this working by introducing a tag type that is assigned to each email tag, i.e. payment, license, vendor, etc. There would be an API for registering tag types that would allow for an extension, such as Software Licensing, to register a type and to specify what object type the primary ID refers to.
If we can do both of those, I'm not entirely sure we need a whole API specific to email settings since registering email settings isn't really any different than other settings, they just have a specific location. The main API that needs reworked is, as @chriscct7 said, the email tags one.
Right, I think that would really help. I think at one point there was a ticket opened for this somewhere, and I would suggest calling it "context" that way you know what the ID is in reference to. For example if context is an order, then the ID can be expected to be an order ID.
Possible contexts: payment, subscription, license, vendor, user, etc
For UX, we'll need some sort of nested system which organizes emails like this:
Emails > Extension/Core > Email Name > Email Fields
In some situations with repeatable emails like Software Licensing it would be organized with another level:
Emails > Software Licensing > Email Name > Email Repeater > Email Fields
I think each email should have a standarized set of fields at a minimum:
- Email Template
- From Name
- From Email
- Subject
- Text Body
- List of available template tags
- Recipients (where applicable)
- Preview Email Button
- Test Email Button
Quick/Dirty mockup to use as a launching point:
@SDavisMedia could we 'steal' the card system for this view? We know that already works well on mobile as well.
Not the full card view, just the way the tabs work and collapse down for smaller screens.
Alternatively, EDD Slack has a pretty good notification management interface. A list like in Phil's example above with each revealing a modal containing the form.
Oh? Does everyone else feel that way too? The main reason Slack uses modals is because Pippin requested we convert to them.
It's one I feel pretty adamant about, if at all possible to avoid.
At this point, that's the only official add-on for EDD that uses modals in the admin I can think of (besides any we may have just acquired and need to update).
Unless they are 100% accessible and work on mobile to the point that they don't have issues on any common device sizes I'd like to avoid them for things like emails.
Furthermore, I cannot think of a single WordPress core modal (other than the 're-authenticate'), and we typically try and remain in line with the practices of WP Core so we don't have to re-train users.
I like the modals on the Slack addon tbh. It makes it far more condensed and easy to read.
I disagree with the mobile argument completely. I agree with things like reports being a mobile friendly, because people look at that for quick reference on their phone, but I doubt more than 2 dozen people have ever edited their email settings for EDD from a mobile phone. If mobile responsiveness is possible it should be done, but we shouldn't go out of the way to achieve it on this when no one (not absolute) will realistically use it for that.
As for the modals in WP core, I don't quite understand the argument there either. There are dozens of modals in WordPress core (you probably interact with many of them so frequently that you don't think of them as a modal, but they are):
- insert media on TinyMCE
- Details link on plugins list table
- advanced link settings on editing a post/page
- upload media modal in Media Library
- Post locking on edit screens
- Connection lost on edit screens
- Re-authenticate modal
- Quick post widget
- Installing an importer on the tools page
- Setting the featured image/media selection
and so forth
An alternative by the way to consider is use the format of the screen in EDD slack settings panel, but then when you click on edit notification, instead of a modal, have the notification edit jQuery slide out under the row where you just clicked edit. So you'd have a textarea field, a save button and a close button (jquery slides back up).
We had some discussions yesterday in slack, and we actually think there is a better solution than a 'settings area' that uses modals.
The customizer is a great tool we could use to take this 'visual' based setting and turn it into a live preview. During the discussion I remembered a talk @BFTrick gave at LoopConf in Vegas that used the customizer to design an email that gets sent to customers, and the ability to use color pickers, image uploads and live previews seems like a great way to handle and completely rethink the process of 'designing' EDD emails.
https://youtu.be/-46mYjL9unM?t=7h13m45s
Stick with it through the beginning of his talk and the name since it references 'Plugin Settings', but I think we could just bring the email editor this interface and have a huge improvement to the email creation experience to EDD.
If your settings control something visual it should be done in the customizer. :) 👍
Using the customizer to show the email + a preview is fine, but I would personally not consider adding any additional customization options for emails beyond what EDD already has.
In addition to a combined vertically-tabbed interface (which i think is great), I'd love to have an UI to show the emails that have been sent and are going to be sent in the future.
Here's an example of an UI, from Churn Buster:
