The branding process in Slate is implemented so that the Slate public pages closely resemble a your institutional admissions web page. Prospective applicants should see a consistent look and feel when moving between pages on an institutional website and form, events, or application pages within Slate. For example, when a potential student clicks the link for a Request for Information/Inquiry form the user should not feel that they have been redirected to a new site.
Requesting Updates to Existing Branding in Slate
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.
Side Navigation Bars
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.
Removal of Dynamic Features, Search and Embedded Forms
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.
Editing branding files
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.
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=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.
Multiple Branding Themes
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.
Mobile Device Branding
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.
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:
1. Navigate to the database page.
2. Click on Configuration Keys, under the Configurations section.
3. Click on the “Insert” link.
4. In the Key field, select “Mobile Template = /shared/build.xslt”
5. In the Value field, type: “/shared/build.xslt” and select Save.
Analytics in Slate Pages
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.