Lucit Template Guide for Third Party HTML Serving

Lucit Dynamic Templates can render third-party served content allowing developers to take advantage of tools and resources they are comfortable with, while still enabling their content to display cross-publisher without the need to design special HTML files for every individual CMS or on-screen player system

This mixed-content approach allows custom code to render within the platform while still taking advantage of Lucit's content triggering, delivery, scheduling, targeting and preview features.

Prerequisite

To serve third-party content, the third-party developer must

• Build HTML/JS/CSS Locally
• Serve the content from an endpoint https://your.company.com/your-content
• Handle all data that needs to appear ON the template, internally within the template
• Ensure that the content test and run on Chromium browsers (Chrome 87 or higher for compatibility with most digital signage)
• Note - Do not use Safari or Firefox.
• Prepare a list of white-listed domains that your content will serve from or fetch from (including API endpoints), as some publishers require white-listing of HTTP requests — include this list when submitting your content URLs to Lucit.

How content is served

Third-party content is served via an iframe which will be sized to 100% of the containing screen. Because of this, it is important that your content is designed to respond to any screen size ratios that are part of your campaign.

A typical iframe serving a remote URL looks like this

 <iframe src="https://your.company.com/your/content"
   style="margin: auto 0px; 
    border-style: none; 
    display: block; 
    pointer-events: none; 
    height:100vh; 
    width:100vw;
    overflow: hidden;"
    ></iframe>

Note the use of 100vh and 100vw

Screen Sizes

Lucit dynamic creatives are designed to respond to the exact size of each screen in your campaign. When the screen renders a creative, a typical flow is like this

1. Chrome browser instance is initialized
2. The browser is set to the specific dimensions of the screen
3. The HTML is loaded into the browser and rendered

Then, depending on the type of platform in use, either this browser displays the content directly, OR, on digital screens that do not support chrome-based browser rendering, this browser is SNAPSHOTTED to a JPEG and then this JPG is displayed on the screen.

Sizing your content

It is important to think in RATIOS versus PIXEL sizes. A screen that is 800x400 and a screen that is 1600x800 will render nearly identically (with a resolution difference) in the browser

You have a few options to handle this

Single Package

Create a single responsive package that uses CSS Media Queries to show the appropriate content for any given ratio. (Note - See Screen Format Reference for a list of common ratio ranges)

For example, if you are building a creative that supports BOTH vertical (1080x1920) AND widescreen (1920x1080) you css stylesheet might look like this

/* BOARD FORMAT MEDIA QUERY : vertical */
@media (min-aspect-ratio: 400/1000) and (max-aspect-ratio: 599/1000) {

    /*
     * Format: vertical
     * Label: Vertical
     * Recommended Size: 1080x1920
     * Aspect Ratio Range: 0.4 - 0.5999
     *
     * Add vertical-specific CSS here.
     */

}
/* END BOARD FORMAT MEDIA QUERY : vertical */

/* BOARD FORMAT MEDIA QUERY : widescreen */
@media (min-aspect-ratio: 1700/1000) and (max-aspect-ratio: 1800/1000) {

    /*
     * Format: widescreen
     * Label: Widescreen
     * Recommended Size: 1920x1080
     * Aspect Ratio Range: 1.7 - 1.8
     *
     * Add widescreen-specific CSS here.
     */

}
/* END BOARD FORMAT MEDIA QUERY : widescreen */

Place all of your styles that change per-format within the appropriate blocks.

You can then test this in your browser by resizing your view using the Chrome Developer Tools

View a list of All CSS Media Queries here

Multiple Package

When building separate HTML packages for EACH FORMAT - Be sure to validate that the content looks good across the entire ratio for that format.

For instance, even though standard bulletin size is 1400x400 when designing bulletin sized creatives - The w:h ratio can actually vary from 3.2666 - 3.717

When providing multiple packages, name them according to the appropriate size format from Lucit Screen Format Reference

Javascript

When using javascript in your templates, plain javascript is typically preferred to complex bundles and libraries.

If you are using libraries and bundlers (such as React, etc.) to generate your javascript file, be sure to set a production chrome target of 87 or higher to ensure your content will run on older digital signage players using older versions of chrome

Snapshot Pre-Generation

Lucit enables snapshot pre-generation for specific campaigns that require it. When enabled by Lucit, JPG snapshots of your creative are pre-generated and sent to older players instead of live HTML, ensuring compatibility with players that do not support Chromium-based rendering.

Load Times

Ensure that your package loads completely (un-cached) within 4 seconds, as measured at the player.

Animations

If you are using animations. Animation playback should wait, and start by listening to the following window message : play_content This ensures that the animations will start playing when the creative is displayed (and not while it is being pre-loaded)

For example

window.addEventListener('message', function (event) {

    if (event.data.type === "play_content") {
        //Execute your code that plays your content
    }
});

Lucit Data / Macros

Lucit Data / Macro values can be sent to your dynamic content URL via the querystring.

This means that any data source attached to your lucit account, or any screen specific macro can be automatically injected on every play

For a complete reference of the available macros see

• Macro Reference
• Application Macro Reference

Example, you might construct a url that looks like this

https://your.company.com/your/content?city_name={digital_board.location.city}&weather_condition_code={digital_board.store.Weather1_current_condition_code}

CORS

If your third-party content makes HTTP requests to external APIs or resources from within the iframe, those requests are subject to browser CORS (Cross-Origin Resource Sharing) restrictions. Ensure that any API or resource endpoint your content fetches returns the appropriate Access-Control-Allow-Origin header.

Include all such domains in the list of white-listed domains you submit to Lucit along with your content URLs.

Testing

To test your package before sending, create a simple index.html as follows

<!DOCTYPE html>
<html lang="en">
  <!-- DriveTemplateBuilder:v4:1781726044 -->
  <head>
  <style>
* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

html {
    height: 100vh
}

body {
    min-height: 100vh;
    height: 100%;
    margin: 0;
    padding: 0;
    box-sizing: border-box
}

  </style>
  </head>

  <body>
    <iframe 
    src="https://your.company.com/your/content" 
    style="
    margin: auto 0px;
    border-style: none;
    display: block;
    pointer-events: none;
    height:100vh;
    width:100vw;
    overflow: hidden;"></iframe>
  <script>
    document.addEventListener('DOMContentLoaded', function () {
      var iframe = document.querySelector('iframe');
      if (iframe) {
        iframe.addEventListener('load', function () {
          iframe.contentWindow.postMessage({ type: 'play_content' }, '*');
        });
      }
    });
  </script>

  </body>
</html>

What to provide to Lucit

After setting up your content, provide Lucit the URL or URLs (if multiple) to your package for testing, along with the complete list of white-listed domains your content serves from or fetches from. We will run a test render and provide back the results