Corners of Sakai 2 – Skinning Site Types

The ability for an institution to configure their local Sakai instance with site types I think underexploited. Or maybe I do not know what people are doing with it. I show how to serve different look and feel for different site types using the same skin. But first – what is a site type?

Let’s say that your institution does not offer courses, but synergymnasiums, no seminars, but collaboratoriums, no discussion sections but hoedowns, etc. These choices can be presented to the user via configuration changes. But it goes beyond the name:  creation of different site types can be associated with different access level people. Maybe only administrators can create synergymnasiums, for example. Each site type also comes with a set of tools to choose from or forced to accept, and after 2.5.x, even with prebaked content into the bargain, etc. There is more to this that am aware of, but for our purposes here, the only thing that matters is that the site type is emitted as a class in the portal markup, allowing us to do different things to a portal depending on the site type. There are 3 spots where this happens:

In the portal masthead:

<div id="siteNavWrapper" class="workspace">
 <div id="mastHead">
  ....
 </div>
</div>

In the site navigation block:

<div class="siteNavWrap workspace">
 <div id="siteNav">
  ...
 </div>
</div>

and in the top most wrapping block of all site content:

<div id="container" class="workspace" >

This means that you can get at, via contextual selectors, to almost any element in the portal, and do different things to it based on the site type.

At the University of Michigan we have 5 significant site types: workspace, course, project, gradtools, and unspecified. Here is how the first three look like, using the same skin:

The user workspace:

The course site:

The project site:

Since a given user will go from workspace to project (at Michigan any user can create project sites) to course site it was important to make sure they were only subtly different – or different enough to help the user locate herself,  not different to force them to remap things between site types. This was done via color only – the color of the banner text (a background image of one of the children of the .mastHead block), the bottom border of the site navigation, the text of the site title, the text of the current tool, other things. The most radical difference was with the workspace banner text – we found our users needed that extra flag to discern between workspace and worksite.

You can take a look at the portal css of CTools if you would like. All of this is documented as well in the source documentation in the reference.

The remaining site type is the undeterminedSiteType – the default. That is literally the name of the class you need to address, or ignore but provide a css default for to take care of:

Since the default will be triggered when the site type is unspecified, and the only possible cases would be during errors (like Site Unavailable above) or admin type sites – where the stakes are high, the reddish color seemed warranted.

Anyways, this is all short on detail – but the documentation linked to above covers that pretty well.