Branding is a crucial aspect of any marketing strategy, as it can make or break an organization's online presence. The branding process in Slate can be implemented so that your Slate public-facing pages closely resemble your institutional admissions web page.

Side Navigation Bars

Right and left-hand side navigation elements are not supported in Slate branding.  The content size will vary depending on which Slate page users are viewing, and this content will not be able to fit on a page with sidebars.

Removal of Dynamic Features, Search, and Embedded Forms

Any features that depend on JavaScript, such as menu pop-ups, often conflict with Slate programming and should be removed when implementing custom branding. If an institution has a web development resource that can provide a CSS template to replace this functionality or otherwise does not use a JavaScript framework like jQuery, they may update the branding using the non-JavaScript template.

Search boxes that use embedded forms can also be sources of conflict with form functionality and should be removed from pages in the branding process.

Custom Branding

Your institution can edit the Slate branding as desired.  If you choose to implement custom code within your Slate branding, please note that we cannot predict how your custom code will interact with Slate code. ALL Slate pages should be tested thoroughly in your Slate test environment before moving any code to the production environment.  

For additional information, please see Test Environments.

🔔 Important

Any custom scripts or other non-Slate code must be maintained by your institution, and we cannot guarantee support of the custom code if problems are encountered.

Editing branding files

In Slate, two files govern how your public-facing pages appear - build.XSLT, which lays out the structure of the page, and build.css, which holds the styles that will be applied to the build.XSLT. In many cases, a build-fonts.css file is also created, which holds custom font definitions. The production versions of these files are inside the /shared path.

We strongly recommend thoroughly testing all edits in your Slate test environment before moving any code to the production environment as errors in these files may cause your external pages to become unavailable.

To view and edit these files, navigate to the Database page in your Slate instance and click File Editor under the Configurations section.

CSS file caching

The CSS files are cached on the server, and therefore changes made to build.css will not be immediately visible. To force an update to the file cache, edit the build.XSLT file and update the version parameter in the reference link to the build.css file:

<link href="/shared/build.css?v=20240917192252" rel="stylesheet" />

Updating the timestamp will trigger a change to the file version. Please note that you may need to allow up to 15 minutes for the updated file to propagate across all production nodes, and you may need to wait a bit longer (sometimes up to 24 hours) for your browser to expire the cached files.

Conditional Branding

It is best practice for a Slate database to have one build.XSLT and one build.css file where the custom branding styles are stored. Conditional branding can be created within a database. This article on Conditional Branding may prove helpful with a general overview and a few examples.

Mobile Device Branding

By default, the mobile branding that is implemented is using the Slate ‘default grey’ mobile template. This minimalist template ensures that Slates content is rendered consistently across all mobile platforms.

Many institutional mobile branding styles reply upon JavaScript. These Javascript features often conflict with Slate programming, resulting in inconsistent rendering and should be removed in the custom branding process.

Before enabling mobile branding using your custom branding template in your production environment, we strongly recommend testing all Slate pages in your Slate test environment to ensure content is rendered as expected on all platforms.

To override the default mobile template and utilize your custom institutional branding:

1. Select Database on the top navigation bar

2. Select Configuration Keys.

3. Find the Branding, Privacy, & Ping section.

4. Select Mobile Template.

5. In the drop-down menu, select /shared/build.xslt.

6. Click Save.

   

Analytics in Slate Pages

Slate fully supports Google Analytics and other analytics platforms with JavaScript APIs for registering page views and conversion events.

📖 Further reading

Add Analytics Tracking to Your Branding Template

Favicons

To add or update your institution's favicon in your Slate database, navigate to the File Editor, available under the Configurations section on the Database page. Click "Upload File," choose "Upload File by URL," and then enter the path to your /favicon.ico. Your path must be /favicon.ico for your favicon to appear.

Please note that you need to allow up to 15 minutes for the file to propagate across all production nodes, and you may need to wait a bit longer (up to 24 hours, possibly) for your browser to expire the cached icon. You may be able to open an incognito window after the 15-minute mark to see the new icon.

Read more about Favicons here.

Need a Favicon Image? A Favicon is a small 16x16 icon that displays next to the URL of your site in a browser's address bar. To get your school's favicon, use this link: http://www.google.com/s2/favicons?domain= www.example.org and replace www.example.org with your institution's site.