Technolutions uses a branding tool that takes an existing site's URL and copies the site's images and styles into files that are saved to your Slate instance to create your Slate branding. By maintaining separate branding files that are not linked to files on your site, it ensure that changes to your institutional website will not cause unplanned changes to the Slate branding.

For more information, review Branding Bookmarklet.

Right and left hand side navigation elements are not supported in Slate branding.  Slate's 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. 

Any features that depend on JavaScript, such as menu pop-ups, often conflict with Slate's programming and are removed in the branding process. If an institution has a web development resource that can provide a template that uses CSS to replace this functionality, or otherwise does not use a JavaScript framework like jQuery, we will update the branding using the non-JavaScript template. 

Search boxes which use embedded forms can also be sources of conflict with Slate’s form functionality and are removed from pages in the branding process.

You 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's code. ALL Slate pages should be tested thoroughly in the Slate test environment prior to moving any code to the production environment. Any custom scripts or other non-Slate code must be maintained by you and we cannot guarantee support of the custom code if problems are encountered.  

For additional information, please see Test Environments.

In Slate, there are two files that 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.  We strongly recommend testing all edits thoroughly in the Slate test environment prior to 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.   

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=20151203192252" rel="stylesheet" />

Update the timestamp which will trigger a change to the file version.   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 files.

Every Slate instance has one build.xslt and one build.css file where the custom branding styles are stored. Embedded forms can be used to customize different registration pages.

Using an embedded form enables you to insert a form into an institutional web page.  The styling of the form will match the page it is embedded into.  The forms will not produce any style of their own when using this method.

When using Slate’s "Embed Form" code from the Edit Form page, Slate uses the <script> tags to inject the form into the hosting page's document object model (DOM), enabling the form to receive all of the CSS styles from the hosting page. 

For additional information on Embedding forms, please review the Embedding Forms.

The mobile view that is implemented is Slate's default mobile template. This template ensures that Slates content is rendered consistently across all mobile platforms.

Many institutional mobile branding styles reply upon a JavaScript. These Javascript features often conflict with Slate's programming and are removed in the branding process, resulting in inconsistent rendering. If your institution has a web development resource that can provide a template that uses CSS to replace this functionality, or otherwise does not use a JavaScript framework like jQuery, we will update the branding using the non-JavaScript template. 

We strongly recommend testing all Slate pages in your Slate test environment prior to enabling mobile branding in your production environment to ensure content is rendered as expected on all platforms. This will allow you to revert back to Slate's default mobile template, and ensure your users have un-interrupted access to your instance of Slate. 

To override Slate’s default mobile view, and utilize your institutional branding, complete the steps below:

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

For additional information, please see the Embedded Google Analytics.

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. 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.