Adding tabs to a portal can help improve user experience by dividing information displayed in a portal into different sections and reducing scrolling. A portal with tabs typically consists of a default view containing the tab menu items and JavaScript, plus multiple additional views for the content under each tab.

Creating a Portal with Tabs

There are five required steps involved in creating portal tabs:

1. Create a view for each tab.

2. Create a method for each tab.

3. Update or create the default view that will contain the tab framework.

4. Within the source code, create links using specific data-tab HTML attributes.

5. Add JavaScript below this HTML code to asynchronously load the tab content.

Step One: Creating the Tab Views

The content of each tab will have its own view. The content in these views will only display when the portal user is on that tab. If there is content that should always appear, regardless of what tab the user is on, then you should leave or add that content to in the default view (discussed in step three).

Tip

Most tab views should use a one-column layout, particularly if the default view is a two-column or another partitioned layout - you don’t want to have a multi-column view embedded inside a multi-column view!

If you are adding tabs to an existing portal, the "Move" button can assist with moving content to various new views.

Step Two: Creating the Methods

Each tab must have an associated method. When the tab is clicked, the associated method is called, which renders the tab view. Use the following settings for each method:

• Name: An internal name for the method. It’s often a good idea to give it the same name as the associated view.

• Type: GET

• Output Type: AJAX Popup/No Branding

• Action: This must be computer-friendly (only using letters and underscores) and a maximum of 32 characters. These values will be used in the tab framework code, and are also added to the URL when the tab is clicked.

• View: Select the associated tab view you created in the previous step

In this example, the “Tab: Home” view has a method named “Tab: Home” and an Action of “home”.

Step Three: Creating the Default View

The default view contains the source code that displays the tabs, as well as anything that should be displayed regardless of which tab is selected.

Important!

If you’re creating a portal from scratch, you may not already have a default view. In that case, make sure to also make a Default method. This method should use an Output Type of Default Branding, and should have a blank value for Action.

In the default view, add a Static Content block and view the source. Copy and paste the following HTML code, which serves as a baseline for your tabs:

<ul class="subtabs">
    <li>
        <a href="#" data-tab="home">Home</a>
    </li>
    <li>
        <a href="#" data-tab="profile">Profile</a>
    </li>
    <li>
        <a href="#" data-tab="directory">Directory</a>
    </li>
</ul>      

Step Four: Adding the data-tab Attribute

In the source code, you'll see that each item has a data-tab HTML attribute. These attributes are used to look up the appropriate portal method for each tab, and therefore must exactly match the Action of the associated method.

You can modify the existing tabs in the example code above or write them yourself. Either way, make sure each tab follows this format:

<li>
  <a href="#" data-tab="method_action">Tab Label</a>
</li>

Step Five: Adding JavaScript

When a tab is clicked, we don’t want to reload the entire page. Instead, JavaScript is used to load the tab content, render it on the page dynamically, and update the current URL. The JavaScript code provided here will work as long as your tab HTML is formatted correctly.

Note that this code also contains some HTML. The div element with the ID content_body is a placeholder element which will contain the tab content once the JavaScript runs. Make sure to copy all of the code in the box below.

<div id="content_body">
</div>
<script type="text/javascript">
/*<![CDATA[*/
var loadTab = function (tab, queryString, isBack) {
if (queryString) {
var qs = FW.decodeFormValues(queryString);
delete qs["tab"];
queryString = FW.encodeFormValues(qs);
queryString = queryString ? "&" + queryString : "";
}
if (!isBack) history.pushState(tab, null, "?tab=" + tab + queryString);
$("a[data-tab]").removeClass("active");
$("a[data-tab='" + tab + "']").addClass("active");
FW.Lazy.Fetch("?cmd=" + tab + queryString, $("#content_body"));
};

window.addEventListener("popstate", function (e) {
if (e.state) loadTab(e.state, location.search.substring(1), true);
else history.back();
});

$("a[data-tab]").on("click", function () {
loadTab($(this).data("tab"), location.search.substring(1));
return false;
});

var qs = FW.decodeFormValues(location.search.substring(1));
if (qs["tab"]) loadTab(qs["tab"], location.search.substring(1));
else {
var default_tab = $("ul.subtabs").find("li > a").eq(0).data("tab");
loadTab(default_tab, location.search.substring(1));
}
/*]]>*/</script>

Styling Tabs with CSS

In the portal view, tabs are added to the Source as list items (<li>) in an unordered list (<ul>). The <ul> element has a class attribute of subtabs. Each individual list item itself contains an anchor (<a>) element, which displays the name of the tab. Each anchor element also has data-tab attribute values that correspond to that particular tab method's action. The active class is added to the anchor representing the current tab being viewed, i.e. the Home tab by default upon first entering the portal, or the tab that is clicked on.

The tabs (specifically, <ul> elements with a class of subtabs, and nested or child <li> and <a> elements) are styled by default CSS as part of Slate's standard branding. This default CSS can be overridden by adding custom CSS rules in the portal editor (i.e. from the main portal editor page, click "Edit" on the upper right).

The following are example CSS rules that you can copy and paste into the Custom CSS Rules editor. You can further customize these rules, as well as add your own, to use your desired properties and values or to better suit your institution's branding.

#content ul.subtabs li a {height: auto; font-size: 14px; text-align: center;}

Set a margin-top of 0:

.part ul.subtabs {margin: 0 0 1em; width:100%;}

Adjust tab width:

.part ul.subtabs li {width:20%;}

Modify tab colors, padding, margin, and apply rounded corners:

.part ul.subtabs li a {background-color: #f5f5f5; color: #000000; padding: 5px 15px; border-radius: 3px; margin-right: 7px;}

Modify color of the "active" tab:

.part ul.subtabs li a.active {color: #fff !important; background-color: #00669e;}

Modify color of a tab upon mouse hover:

.part ul.subtabs li a:hover {background-color: #fafafa !important; color: #00669e !important;}

Conditionally Display Tabs

You may want to only display certain tabs if the end-user meets certain criteria. To do this, you’ll need to:

• In any relevant query, add an existence export that checks for the desired criteria

• In the default view, use Liquid Markup to conditionally display the tab itself

• Prevent the tab from rendering if the tab URL is entered but the end-user doesn’t meet the criteria

For example, in an alumni interviewing portal, you might only want the “Assignments” tab to display if the portal user has a “Captain” role assigned in a custom field. In the query associated with the default view, we add an existence export called “captain”:

In the default view, we edit the source code and place Liquid Markup around the <li> tags:

Finally, in the “Tab: Assignments” view, we wrap the everything in the source code with our Liquid Markup. If someone were to attempt to view this tab by editing the URL or using an old bookmark, nothing would render on the page.

Another approach would be to use a portal redirect. If your tab view has multiple widgets, or it’s otherwise impractical to wrap the entire thing in Liquid Markip, a redirect will prevent the tab from loading in the first place.