Call To Actions

[fpcorso]

Describe the feature request

This would add the ability to set the "goals" of a popup as well as add the correct action elements needed.

Use case

An admin could set the call to action as "Apply Discount" which would add a button to the popup. When the button is clicked, it will automatically add the discount to the WooCommerce checkout page.

Example screenshots

Top part of Ahoy call to actions:

Latest proposed admin UI for example button CTA:

Steps during a CTA event

1. Have a class that handles CTA's
2. Have a block that layers on top of that system
3. We add that block to our popup, and choose the type, text, and URL using the block settings
4. A site visitor clicks that button which has the href already
5. The CTA success event also triggers an AJAX request which will contain a hook
6. I'm assuming we also use that hook/endpoint to update conversion counter data too, right?

The last few steps may need adjusting to properly track the conversions.

As for the final blocks/types, we are currently planning one block per type, e.g. Button CTA and Add To Cart CTA.

[fpcorso]

@danieliser The first thing for us to decide is the "where" for this in PM. I'm thinking it should go in the popup settings between "Targeting" and "Display".

Would you agree?

[danieliser]

@fpcorso if not there, then replacing the first tab at some point.

My biggest question is should we consider this as part of the planned #348. I could forsee users inserting a button, and then setting up an "action/event" of On Button Click -> Add Item to Cart.

Alternatively can see it being kept separate too. But just thought I'd bring it up as this seems like the ideal time.

[fpcorso]

@danieliser Been brainstorming a bit on this and mapping ideas out on the whiteboard. I think these should be two separate things. The event/action manager of #348 would be things that happen once an event happens. The CTA's are adding something to the popup that can then cause an event.

So, using CTA's, they could add the subscription form. Using the action manager, they could have the popup close when the form is submitted.

This works for almost all CTA's I thought through with one main exception: e-commerce CTA's. The "add to cart" type has the item added to the popup and the action being tied together so that's where having these as separate could be confusing. So, my thought is that we could auto-add actions when someone chooses to add a "add to cart" or "apply discount" type of CTA.

That said, if we utilize the actions manager to handle the second part of the CTA's or if we put the CTA's completely in the action manager, we would need to build the action manager first which is slated for 2.0. So, we'd have the punt this to 2.0 or 2.1 unless we decided to keep all of CTA's completely separate.

[danieliser]

@fpcorso I completely agree with the first part. That said I do think we could look at Add Item to Cart or Apply Discount as the call to action itself still.

To be either the event is the button click and action manager handles "ALL" post click actions such as going to new page etc, OR, it handles none of them and is purely focused on events other than any one particular CTA.

Of course there may be a Clicked CTA event they can attach actions to such as setting cookies etc, but the CTA could be considered a self contained aparatus that way, with hooks (events) for external connectivity.

[fpcorso]

@danieliser Yeah, maybe the CTA system handles its own system end-to-end and then the action manager would allow people to layer additional events on top of anything the CTA adds.

So, in that case, we could build the CTA's system prior to the action manager system. If these are two separate systems then, do we continue with having a new "Call To Actions" tab in the popup settings after "Targeting" or is there a better place/name for it?

[danieliser]

@fpcorso Wouldn't it be more like structured content? So a shortcode and Block?

[fpcorso]

@danieliser I don't quite follow. Can you elaborate a little more on your question/thought?

[danieliser]

@fpcorso sure, I mean calls to actions are a type of structured content which can be placed anywhere in general. So I'd think a shortcode, gutenberg block, and later maybe beaver builder module, VC block etc would be suitable to insert them.

We just need to make an interface that bridges all those. Pretty close already since we have the Shortcode UI framework already built out with JS form rendering.

[fpcorso]

@danieliser Oh, so you want to take a different approach than how we do it in Ahoy? I thought we were just porting over the ahoy system which would be a tab in the settings and auto-appending in a fixed location within the message.

Yes, I could see a benefit to allowing people to add it anywhere using shortcodes/blocks, but would that make the UI less intuitive then and less discoverable since they'd have to know about the block in order to use it?

[danieliser]

@fpcorso With us moving towards fully embracing the new editor as well as other page builders, I think this makes more since.

If we only allow adding it to the end of the popup that might seem overly limiting within the context of the other builders.

We could still have some controls in a CTA tab just to bring awareness, then let them know about the block/shortcode once there.

I don't however know that we should put all the CTA settings themselves in the tab because that decouples the block/shortcode from its settings, and I can fathom scenarios where you might want multiple CTA's in a single popup.

[fpcorso]

Punted to 1.13 as discussed in Q3 check-in call.

[fpcorso]

@danieliser Hmmm.... lots to consider there. Since people are using this CTA inside of popups, slide-ins, bars, etc.. I would imagine needing more than one would be extremely rare. However. getting people to use at least one should be a high priority as almost all of our focus (lead gen, opt-ins, ecommerce) would be CTA-able. So, we should make sure this is discoverable and intuitive.

That said, I think your points on it being built as a block as solid so I think we could heavily consider that. However, right now, only 5% of our users create popups using the block editor. If we add CTA's to the block editor and want that to be a major feature, we would need to make the block editor the default editor for popups before or at the same time as CTA's are introduced.

As for the settings, if the CTA is a block, I would think the best place for the type, text, etc... would be within the block's settings. But, then I am not sure how people would discover as it wouldn't be entirely noticeable as part of Popup Maker's offerings.

[danieliser]

@fpcorso Couple of notes:

1. We would do it in a way that wasn't just blocks, so a shortcode using the current builder would work too for most things.
2. If we go full block editor in the future, it will also likely include premade layouts of sorts that include default content, including but not limited to a CTA.
3. There should be some underlying definition for each CTA type, then an interface to convert it for Shortcode Builder, Gutenberg block, Elementor module etc.

[fpcorso]

@danieliser Okay, so we need:

1. A class/system that handles call-to-actions and outputs a button or necessary code, such as a form
2. A system that exposes that to the admin, starting with a shortcode and a block

Then, what happens when a site visitor clicks the button or submits the form? Will it fire a hook that anything hooks into which we would have our call-to-actions also hooked into?

What types should be in the free version to start with? Maybe link/button/redirect and forms (e.g. NF, GF, CF7)?

So, if we want to add a button to send people to a new page, such as a FB group, we would:

1. Have a class that handles CTA's
2. Have a block that layers on top of that system
3. We add that block to our popup, and choose the type, text, and URL using the block settings
4. A site visitor clicks that button which has the href already
5. The CTA success event also triggers an AJAX request which will contain a hook
6. I'm assuming we also use that hook/endpoint to update conversion counter data too, right?

[danieliser]

@fpcorso so far so good, will clarify much of the collector and interfacing is done for Shortcodes, Shortcake UI & PM Shortcode button. It needs to be abstracted into actual classes and interfaces going forward likely, and we need one to transform it for a Gutenberg block.

Then, what happens when a site visitor clicks the button or submits the form? Will it fire a hook that anything hooks into which we would have our call-to-actions also hooked into?

In Ahoy it works something like this, if its something that can be handled reliably over a redirect, that is preferable as its tracked more reliably. In those cases to keep the need to pass all the CTA options through the url exposing them, we pass the mid or in this case the pid and simply let the logic via PHP take over and do necessary actions like add items to cart, set cookies etc.

This might not work if they insert CTA's as blocks, in Ahoy CTA options are part of the message settings. Here they may not be so we will need to make considerations for that I'm sure.

The alternative when necessary is JS based CTA actions and they would fire beacon hits. These do not work for urls at all, the browser changes pages so quickly most servers don't receive the beacon request in time.

Now of course we can make this a bit more refined in PM and use the PUM.hooks library to add filters/actions where we need them in JS as well as in PHP.

What types should be in the free version to start with? Maybe link/button/redirect and forms (e.g. NF, GF, CF7)?

Yea that sounds about right. I do have issues with how Ahoy handles the form CTA. Not really sure that is viable. Hiding the text and showing a form is a weird UX that I never really liked.

Any thoughts? In general the CTA might not be inserted if you use a form as the form submit button would be the CTA. In those cases we already have options for handling post submission stuff and conversions will be tracked already as well.

So I'm not sure we really need to add another CTA specifically for them. In ahoy it showed the form, here it makes less sense to do that I think. Might be one of the few things I don't care to port from Ahoy haha.

So, if we want to add a button to send people to a new page, such as a FB group, we would:

4, 5 & 6 in your list may need tweaking to make tracking completely reliable, see notes above. But otherwise yes.

[fpcorso]

@danieliser Hmmm.... yeah, since we have the form integration system already built out and it will handle conversions already, you may be right that we do not need to add forms into the CTA system.

So, the block settings need to be something like this, right?

For block settings, can we dynamically show different fields? For example, if it's a button, we need text and URL, but when we add apply discount, we would need other fields.

Or, do we have a separate block for each type? That would make it easier to see the available types, but there are downsides there too.

For the block, do we also need to have color and font settings like on the default button block? Would those settings also be available in the shortcode then too?

[danieliser]

@fpcorso Yea we can do a lot of cool dynamic stuff using React.

For example since every redraw includes the full values of all other fields and block info (position etc) you can dynamically show /hide fields simply by doing something like this

( values.type === 'button' && <URLInput value={values.url} /> )

Essentially if values.type isn't 'button' the second part (the URLInput element would never get run and in this case rendered.

To map things properly between our existing JS Form setup and React we might need a layer of logic that converts and handles field dependencies dynamically as opposed to hard coded like the example above.

For example each field before rendering might call a new JS function that checks our field declarations against current values and determines true/false if that field should be shown.

Without a clever method like that we will have to hard code all if value = x show this hide that etc.

What downsides do you imagine there being for having a different block type for each CTA? Not arguing either way but I didn't see the negatives other than just more code.

The block might have more options, but that leads to a question whether there should be options in the theme editor to style CTAs, which brings me back to the idea the theme editor might be something of the past and we should reimagine it going forward like we've eluded to a few times.

If the content styling is eventually to be handled by the blocks / builders themselves, I'm not sure how far we should go to allow styling things elsewhere. Moving the popup styling into the popup editor would simplify that as well at some point I imagine, but that is all another issue.

[fpcorso]

@danieliser For the styling: since we are expecting to use these outside of popups too, I don't think it makes sense to have any of the styling within the theme editor, even if we do end up keeping that.

For the individual blocks for each type: My main concern would be that we might be adding 5 to 10 of these over time so it would require them to make sure they go through the list to find the right block prior to adding. And, since other plugins may add call-to-action named blocks, we'd have to add our name to it so it could get long if they are individual types such as "Popup Maker Call To Action Add To Cart."

[danieliser]

@fpcorso One possibility is instead of prefixing them with Popup Maker add the logo as an svg or icon there instead.

That said we can also limit our CTA's to only our post types among other things to prevent that confusion.

One argument to be made for a single CTA is the ability to quickly swap a CTA to another action, BUT, Gutenberg already includes a block morphing tool which can translate one block to another type, so this is not really a great reason.

Could go either way. Might be worth running by the UX team 😃

[fpcorso]

@danieliser Updated the original message for this issue trying to recap most of the conversation, since we are slated to start implementing this in a little over 2 weeks.

What about the name itself? Are these "Call to actions" or should we just call them "Actions" or maybe something else? I think "Call to actions" still might make sense but is there a better name to better convey exactly what these are and how to use them?

[danieliser]

I think CTA makes the most sense currently given their purpose.

[fpcorso]

@danieliser Okay, sounds good.

Are there any other decisions or workflows that we need to think through before you start working on this in 2 weeks?

[danieliser]

This feature is pretty much ready for testing but a few issues have come to light:

1. This solution limits users to blocks and shortcodes.
2. Page builders would require using the shortcode.
3. Shortcode & blocks are limited in styling options to what we provide.
4. Adding styling options for full control will be a pain over time to keep maintained.

I'm currently exploring an alternative method that would be compatible out of the box with all of these builders, editors etc, letting them use the existing styling options available to them.

Punting for now.