Conditional Branding

Conditional branding can be created within a database, but implementing it falls outside the scope of Service Desk assistance. Due to its inherent complexity and uniqueness to each institution, we cannot help you develop, implement, or fix behavior related to conditional branding. However, this article may prove helpful with a general overview and a few examples.

Remember, it is up to your institution to implement, troubleshoot, and maintain any custom conditional branding. It is our recommendation to have one consistent branding for your entire instance.

General Recommendations

Keep it simple. Get default branding in place first, then work on iterations. For a number of reasons, conditional branding should not be excessively complex. We recommend making simple adjustments, such as swapping a different image or logo or adjusting a footer or header. Like many aspects of Slate, we encourage you to thoroughly test to ensure that the branding works as expected before bringing the change into Production. We recommend using the Branding Editor to conduct testing. The Branding Editor tool enables the editing and previewing of Slate branding while keeping the current branding files unchanged. It provides previews of how branding would look for a specific record or URL.  

Once you start putting conditional branding into place, all necessary information may not be available at various spots, so we recommend thoroughly testing and including defaults in conditionals. Again, remember that this use of conditionals is outside the scope of Service assistance.

  Best Practices

Conditional branding misbehaving? We recommend using Version History in Files to roll your branding back to the last time it appeared as expected.

There are many ways to approach conditional branding. The following examples are provided to demonstrate what is possible.

Conditional Branding for an Application

We recommend Choose and Contains statements over If statements in your conditional branding because If statements can cause loopholes. For changes based on application, we recommend using the round-key. For example, your institution might have different logos that appear based on round-key. Here the rounds are UG and GR, and each program has a corresponding image.

  1. In the main Slate navigation, click Database.
  2. In the Configurations section, click Files.
  3. On the right side of the page, locate and click shared.
  4. From the list of files, locate and select the line that includes build.XSLT. The Edit File tool opens.
  5. Create an XSL variable called "roundKey" to act as a reference in the rest of the page:
<xsl:variable name="round-key" select="*/fw:template/@application-roundKey" />
  1. In the appropriate place in your HTML, add code that selects the correct image based on round-key. This code may look something like the following:
<xsl:choose>
      <xsl:when test="(contains(fw:pathAndQuery(), '/apply') and $roundKey = 'UG')">
           <img src="/images/sample-A.jpg" alt="Home" class="cr" style="logo-image" />
      </xsl:when>
       <xsl:when test="(contains(fw:pathAndQuery(), '/apply') and $roundKey = 'GR')">
           <img src="/images/sample-B.jpg" alt="Home" class="cr" style="logo-image" />
       </xsl:when>
         <xsl:otherwise>
               <img src="/images/sample-default.jpg" alt="Home" class="cr" style="logo-image" />
       </xsl:otherwise>
  </xsl:choose>

  Note

Applicants will only see application-specific conditional branding once they've started an application and established a round key.

Conditional Branding for a Form

Our recommended best practice is to embed forms on pages or domains with the desired branding and not utilize conditional branding. If you were to go forward with conditional branding, you could use the form's path.

For example, if you want to display some additional text on your inquiry form page, your code may look something like this:

<xsl:choose>
<xsl:when test="contains(fw:path(), '/register/inquiry')"> You are on the inquiry page!
</xsl:when>
<xsl:otherwise>
</xsl:otherwise>
</xsl:choose>

Other Variables

Other XSL variables—apart from round-key and path—can be created by calling functions in the Framework library (fw:). For reference, here are some others:

query() Everything after "?" in a URL. For example, ?cmd=submitted
url() The full URL of the request. For example, https://apply.slate.university.edu/apply/status?cmd=submitted
https() The subdomain used by an instance. For example, https://gradadmissions.slate.edu
config(key) Get the value of any config key set for the instance.

 

Was this article helpful?
0 out of 0 found this helpful