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.
Below are some popular topics related to Slate branding.
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.
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.
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. 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.
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.
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.
The mobile view that is implemented is the Slate default mobile template. This 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.
We strongly recommend testing all Slate pages in your Slate test environment before enabling mobile branding in your production environment to ensure content is rendered as expected on all platforms. This will allow you to revert to the Slate default mobile template and ensure your users have uninterrupted access to your instance of Slate.
Override the default mobile view and utilize your institutional branding:
- Select Database on the top navigation bar
- Select Configuration Keys.
- Select Insert. A popup appears (pictured).
-
In the Key field, select “Mobile Template = /shared/build.XSLT”
-
In the Value field, type: “/shared/build.XSLT”
- Click Save
|
 |
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. 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.
