SOLVED

Removing a landing page element instead of just hiding it

Go to solution
msutton
Level 2

Removing a landing page element instead of just hiding it

Today I realized that if I select to hide a template section it does actually just hide it (display: none) vs. removing from the final HTML. This means every template element - including unoptimized placeholder images - are being loaded every time on every LP that uses a particular template.

 

Now that we have a bunch of LPs based on our QuickStart template, I'm thinking through my options to stop loading hidden content with every page load.

I'm nervous about just deleting sections from the template itself because I don't know for sure which sections are used where or not.

I'd also like to continue using guided templates. But if this is the trade off then I'm not sure.

 

Any advice?


Mike Sutton
Marketing Operations | DNSFilter.com
1 ACCEPTED SOLUTION

Accepted Solutions
Dave_Roberts
Level 10

Re: Removing a landing page element instead of just hiding it

Hey Mike, good catch here - you're spot on about the "hide" vs. "remove" bit in Guided Landing Pages, it's a bit of a thorn - especially if you have one of those "kitchen sink" templates with a different section for each use-case (Speakers, Hero, Event, ...).

If you are using a kitchen sink style template, you can help your future self out a little by creating "Starter Layouts" that are specific to your use-cases (Webinar, Event, Thank You...) and use those like a "master Xerox copy" to produce new pages based on a specific layout. In this way, you can go thru each use-case Starter Layout and eliminate most of hidden content by deleting it in the unused sections and then cloning your Starter Layout each time (rather than starting a new LP based on the template) -- this'll save you the step of removing it every time compared to starting w/ a new page based on the template.

 

Here's a few approaches to consider that might help get the wheels turning:

 

One way to go about completely removing a section from the template would be to use snippet containers rather than editable text areas [at the template level] so that you could easy remove an entire section (snippet) at a time [at the page level] when you weren't using it. The issue with this approach is that you'd have to have a different snippet for each section on each page, so you wouldn't really get the 1-to-many feature out of your snippets unless the content was identical on different pages (or you tokenized your snippets like a madman). I doubt this is a tenable solution for the future b/c it'll make for a ton of snippets to manage, but it's one way to go about it.

 

Another way that I've tackled this issue in the past is to re-think the way Guided LP templates are built -- we did the kitchen sink thing for a while a few years back and ran into similar issues as you're mentioning here. The work around I'm most comfortable with now has to do with building the template to have an identical architecture from section-to-section that has variables you can use to move around and resize the editable areas as needed. Each section contains editable text areas that are identical from section-to-section so that the pieces inside those editable areas can be moved around the page (thus eliminating the need for a bunch of extra use-case specific section that you'd have to hide with a toggle or something. This let us cut most of our pages down from 13-15 sections (kitchen sink) to 5 (include the head/foot) so there's much less junk to hide and it's not big deal to add/remove pieces as necessary.

 

Finally, I've also seen a few solutions to this (more so for EM than LP) that use a toggle variable to add/remove a comment from around an editable section in the html so that when the toggle is turned to "OFF" it actually comments out the code between the comments (thus removing it from the code [render] but still leaving it "on the page" for when you turn the toggle to "ON" again).

One important thing to note with this approach is that the code will be commented out by default until the variable renders. This means you can't wrap this around an editable area on the template b/c then it doesn't work in the editor (b/c of the load order). 

 

Here's an example of what that might look like -- here's a metatag (Boolean Toggle) variable for the <head> of your template and an example of that variable in play in the <body> of your template somewhere (probably wrapping around your sections):

<head>
   <meta class="mktoBoolean" id="Section-Display" mktoName="Section Display" default="true" true_value="--" true_value_name="ON" false_value=" " false_value_name="OFF">
</head>

<body>
<!-- ${Section-Display}>
   <section>
      ... add stuff here to toggle on/off w/ a comment
   </section>
<!-- -->
</body>


WHICH RESULTS IN: [notes in brackets for context]

Scenario 1: Toggle set to TRUE aka "ON"

<!-- --> 
... add stuff here to toggle on/off w/ a comment [this stuff shows up]
<!-- -->

 

Scenario 2: Toggle set to FALSE aka "OFF"

<!-- > 
... add stuff here to toggle on/off w/ a comment [this stuff is hidden]
<!-- --> 

 

 

View solution in original post

3 REPLIES 3
Dave_Roberts
Level 10

Re: Removing a landing page element instead of just hiding it

Hey Mike, good catch here - you're spot on about the "hide" vs. "remove" bit in Guided Landing Pages, it's a bit of a thorn - especially if you have one of those "kitchen sink" templates with a different section for each use-case (Speakers, Hero, Event, ...).

If you are using a kitchen sink style template, you can help your future self out a little by creating "Starter Layouts" that are specific to your use-cases (Webinar, Event, Thank You...) and use those like a "master Xerox copy" to produce new pages based on a specific layout. In this way, you can go thru each use-case Starter Layout and eliminate most of hidden content by deleting it in the unused sections and then cloning your Starter Layout each time (rather than starting a new LP based on the template) -- this'll save you the step of removing it every time compared to starting w/ a new page based on the template.

 

Here's a few approaches to consider that might help get the wheels turning:

 

One way to go about completely removing a section from the template would be to use snippet containers rather than editable text areas [at the template level] so that you could easy remove an entire section (snippet) at a time [at the page level] when you weren't using it. The issue with this approach is that you'd have to have a different snippet for each section on each page, so you wouldn't really get the 1-to-many feature out of your snippets unless the content was identical on different pages (or you tokenized your snippets like a madman). I doubt this is a tenable solution for the future b/c it'll make for a ton of snippets to manage, but it's one way to go about it.

 

Another way that I've tackled this issue in the past is to re-think the way Guided LP templates are built -- we did the kitchen sink thing for a while a few years back and ran into similar issues as you're mentioning here. The work around I'm most comfortable with now has to do with building the template to have an identical architecture from section-to-section that has variables you can use to move around and resize the editable areas as needed. Each section contains editable text areas that are identical from section-to-section so that the pieces inside those editable areas can be moved around the page (thus eliminating the need for a bunch of extra use-case specific section that you'd have to hide with a toggle or something. This let us cut most of our pages down from 13-15 sections (kitchen sink) to 5 (include the head/foot) so there's much less junk to hide and it's not big deal to add/remove pieces as necessary.

 

Finally, I've also seen a few solutions to this (more so for EM than LP) that use a toggle variable to add/remove a comment from around an editable section in the html so that when the toggle is turned to "OFF" it actually comments out the code between the comments (thus removing it from the code [render] but still leaving it "on the page" for when you turn the toggle to "ON" again).

One important thing to note with this approach is that the code will be commented out by default until the variable renders. This means you can't wrap this around an editable area on the template b/c then it doesn't work in the editor (b/c of the load order). 

 

Here's an example of what that might look like -- here's a metatag (Boolean Toggle) variable for the <head> of your template and an example of that variable in play in the <body> of your template somewhere (probably wrapping around your sections):

<head>
   <meta class="mktoBoolean" id="Section-Display" mktoName="Section Display" default="true" true_value="--" true_value_name="ON" false_value=" " false_value_name="OFF">
</head>

<body>
<!-- ${Section-Display}>
   <section>
      ... add stuff here to toggle on/off w/ a comment
   </section>
<!-- -->
</body>


WHICH RESULTS IN: [notes in brackets for context]

Scenario 1: Toggle set to TRUE aka "ON"

<!-- --> 
... add stuff here to toggle on/off w/ a comment [this stuff shows up]
<!-- -->

 

Scenario 2: Toggle set to FALSE aka "OFF"

<!-- > 
... add stuff here to toggle on/off w/ a comment [this stuff is hidden]
<!-- --> 

 

 

SanfordWhiteman
Level 10 - Community Moderator

Re: Removing a landing page element instead of just hiding it

There's also a method using a <template> element for hidden modules. This solves the the worry about images loading, though doesn't stop the template markup itself from being transferred.

 

The fact that the initial markup is left in the body is why I recommend (a) having the module name be as self-explanatory as possible and (b) having placeholder images be accessible only inside your network. Showing the world your creative guidelines is not so great.

msutton
Level 2

Re: Removing a landing page element instead of just hiding it

Thanks for this detailed response, Dave. It's very helpful. I'll dig into the options further. I'll likely end up creating a set of more customized templates. But I do like the flexibility of just being able to add/remove modules easily.


Mike Sutton
Marketing Operations | DNSFilter.com