More on Sakai 3 skins

August 27, 2010

In this post we customize the default look of a Sakai 3 installation (gateway and as many logged-in-user subsequent screens as we can identify) and create a few modest skins that users can pick for their sites. The aim of of this is to puzzle out the best process, figure what the stumbling blocks are, and identify the gaps if any.

I will try to post next about conclusions, in a less discursive manner.

The gateway

I have touched on this previously in a non-serious vein.

Institutions with many resources can and should tailor the gateway to suit. It does not need to have the present markup and functionality structure. The possibilities are limitless, more so than in Sakai 2. On the other hand, in Sakai 2 there is a set of known configurations that an adopter can easily set to produce a gateway that is perfectly acceptable:

  • Login (internal, CAS, primary and secondary)
  • Appearance (the gateway can have it’s own skin, be defined in the default skin, or inherit from the defult skin)
  • Institutional messages are possible
  • Institutional links in footer are configurable
  • Etc.

In Sakai 3 the process of customizing the gateway seems more open ended. The exercise below covers the case of an institution that does not have many resources to change the gateway framework, and can affect just the look.

dev/index.html

I added a .masthead wrapper to .header-title and .header-byline. The design I received required it as I explain below. An aside: in Sakai 2 modifying the structure of the portal in this manner would have been harder.

<div class="masthead fl-centered">
    <!-- HEADER -->
<div class="header-title">
       <img src="_images/sakai_logo_index.png" alt="__MSG__INSTANCE_NAME__" />
    </div>
<div class="header-byline">
        __MSG__HEADER_BYLINE__
    </div>
</div>

This will allow us to have superimposed background images – one in .masthead and the other one in .header-title, see below.

dev/_css/sakai.index.css

Change the background:

html {
    background: #093b52 url(../../_images/umich_bg.gif) top left repeat;
}

Style the added wrapper, it gets a repeating background to match the UM logo background:

.masthead {
   height:100%;
   overflow:hidden;
   width:100%;
   margin-bottom:3px;
   background: url(../../_images/umich_banner_bg.png) top left repeat;
}

Style .header-title – giving it a background to display the sanctioned University of Michigan logo

.header-title{
  color: #08415E;
  font-size: 4.0em;
  float: left;
  margin: 0;
  padding: 0;
  background: #fff url(../../_images/umich_banner.png) top left no-repeat;<
  width:500px;
  height:79px
}

Hide the original Sakai logo

.header-title img{
   display:none
}

Hide the byline

.header-byline{
   display:none
}

Hide the Sakai logo in the footer

#footer_logo {
  display:none
}

Style the links in the footer

.sakai-footer .fixed-container a {
    color:#fff !important;
    text-decoration:underline;
}

Note !important, more on that later.

Here is the result so far. Not very exciting, I know – but the major requirements (family resemblance to institutional gateway, adherence to the institutional web style guides) are on their way to be met.

Other things that are in this screen that properly fall within a “branding” scope are the preview image, the link colors, the button colors.

Reminder: the gateway framework is not an immutable given – am just treating it as such.

Other pages

After you log in other rendering mechanisms come into play: new pages call different stylesheets, etc. Carrying out the stuff below takes care of mysakai.html and with some exceptions that will be noted and dealt with, all of the “my” pages (Inbox, Contacts, Profile, Inbox). Yay!

dev/_css/sakai.base.css

Added

.header{
   background: transparent url("../../../dev/_images/umich-transparent.png") left top repeat-x;
}

umich-transparent.png is transparent bottom 1/3rd, top 2/3ds the color of the tab at top:

<div class="personal-container fl-force-right">
    <div class="personal">
        <ul>

containing links to the hidden institutional login, user name and menu, the mail icon, help and sign out links.

This gives us a nice top area that ties in the tab mentioned above, the search area and then transitions into the main content area, pretty much following the original.

What if the needs of the institution dictate this gray area needs to reflect the school palette? For example – if instead of #86898B it needs to be #3A5E8C (following the UM identity guidelines at http://www.logos.umich.edu/web.html)

Things get complicated:

dev/_css/sakai.base.css

Edit the image referenced here so that the top 2/3 matches the new color (#3A5E8C)

.header{
    background: transparent url("../../../dev/_images/umich-transparent.png") left top repeat-x;
}

devwidgets/navigationchat/css/navigation.chat.css

Change the background color of #navigationchatcontainer from #86898B to #3A5E8C:

#navigationchatcontainer{background: #3A5E8C}

That was the easy part. The “personal” tab also needs to match that color.

Still on devwidgets/navigationchat/css/navigation.chat.css

The tab is composed of 2 sliding door images and a background color.

.explore_nav .personal-container {
    margin-top: 10px;
    background: url('../../../dev/_images/topBar_tr.png') top right no-repeat;
    padding-right: 5px;
    overflow: hidden;
}
.explore_nav .personal {
    padding: 4px 0 0 5px;
    margin: 0;
    background: url('../../../dev/_images/topBar_tl.png') top left no-repeat;
    min-height: 30px;
}

Change to

.explore_nav .personal-container {
    margin-top: 10px;
    background: url('../../../dev/_images/umich_topBar_tr.png') top right no-repeat;
    padding-right: 5px;
    overflow: hidden;
}
.explore_nav .personal {
    padding: 4px 0 0 5px;
    margin: 0;
    background: url('../../../dev/_images/umich_topBar_tl.png') top left no-repeat;
    min-height: 30px;
}

With this new background color the link separators need to be made lighter, change the border-left from #666a6d to #aaa

.explore_nav .personal li a {
    font-size: 9pt;
    padding:0 5px 0 7px;
    border-left: 1px solid #aaa;
    color: #fff;
}

And here is the University of Michigan “My Sakai” page.

One thing that remains to be done is adjusting the separators between the links in the “explore” link set at the top. Since the separators are not the same color as the background they bleed into the blue (see below). An easy fix is to give the border-left not to the LI but instead to the child A.

From

.explore_nav ul.explore li {
    padding: 0;
    padding-bottom: 6px;
    border-left: 1px solid #878a8c;
}
.explore_nav .explore li#nav_my_sakai_link { border-left: none; }
.explore_nav .explore li a {
    height:16px;
    color:#fff;
    padding: 8px 20px;
    text-align: center;
    display: block;
    float: left;
    font-weight: bold;
}

To

.explore_nav ul.explore li {
    padding: 0;
    padding-bottom: 6px;
}
.explore_nav .explore li#nav_my_sakai_link a { border-left: none; }
.explore_nav .explore li a {
    height:16px;
    color:#fff;
    padding: 8px 20px;
    text-align: center;
    display: block;
    float: left;
    font-weight: bold;
    border-left: 1px solid #878a8c;
}

Finally – the top rounded corners of the main content area are still expecting a #86898B background. These corners are created by background images referenced in

dev/_css/sakai.core.2.css

.header .fixed-container {
    background: #fff url('../../_images/header_l.png') top left no-repeat;
}
.header .fixed-container .decor {
    background: url('../../_images/header_r.png') top right no-repeat;
    height: 5px; margin-right: -20px;
}

Change to:

.header .fixed-container {
    background: #fff url('../../_images/umich_header_l.png') top left no-repeat;
}
.header .fixed-container .decor {
    background: url('../../_images/umich_header_r.png') top right no-repeat;
    height: 5px; margin-right: -20px;
}

duplicate and edit the 2 images to reflect the new background.

And that is enough for now. One could argue that with the new background the “Search” button needs to be a different color for contrast. We would need to nip over to:

dev/_css/sakai.base.css

and do some heavy styling to get just this button (and any other search button that shows in same background) to show new background color in all it’s states. I have not explored this but it would be a requirement and am sure it is perfectly feasible.

One final wrinkle. If I navigate somewhere else (try to search something, for example) the bottom background of the “search” area will disappear and the corners we fixed previously are misbehaving again.

We need to go over to:

dev/_css/sakai.search_b.css

and adjust the following selectors:

.content_search { padding: 12px 0 0 0; }
.search-container .content_search .fixed-container {
    background: #fff url('../../_images/header_l.png') top left no-repeat;
}
.search-container .content_search .fixed-container .decor {
    background: url('../../_images/header_r.png') top right no-repeat;
    height: 5px;
    margin-right: -20px;
}

to

.content_search {
    padding: 12px 0 0 0;
    background: transparent url("../../../dev/_images/umich-transparent.png") left top repeat-x;
}
.content_search a {
    color: #006E96;
}
.search-container .content_search .fixed-container {
    background: #fff url('../../_images/umich_header_l.png') top left no-repeat;
}
.search-container .content_search .fixed-container .decor {
    background: url('../../_images/umich_header_r.png') top right no-repeat;
    height: 5px;
    margin-right: -20px;
}

Much better:

Finally – the footer, that we addressed in the gateway, needs to be addressed again for screens where the user is logged in:

devwidgets/footer/css/footer.css

Hide the Sakai logo and style the links in a more neutral manner:

.sakai-footer img{display:none}
.sakai-footer .fixed-container a {
    color: #fff;
    text-decoration:underline;
}

Specific site/page looks

When creating a site we have the choice to change the appearance. The appearance files are contained in the dev/_skins directory.

Edit dev/_configuration/config.js to include the info on what site appearances are possible. In our case we need skins for the School of Business, The School of Medicine and Literature, Science and the Arts.

Site: {
  Styles: {
    bus: {
      name: "Ross School of Business",
      image: "/dev/_skins/bus/images/thumb.png",
      URL: "/dev/_skins/bus/bus.html"
    },
    lsa: {
      name: "LS&amp;A",
      image: "/dev/_skins/lsa/images/thumb.png",
      URL: "/dev/_skins/lsa/lsa.html"
    },
    med: {
      name: "School of Medicine",
      image: "/dev/_skins/med/images/thumb.png",
      URL: "/dev/_skins/med/med.html"
    }
 }
},

Then create the first one, in this case the school of Business. I just copied the “original” skin and modified all the paths, file names and references, radically simplifying it. Here is the new structure.

Our requirements are modest – let’s say a logo on the page is good enough for unit identification. In order to add a logo to just the page (site, space, etc) I had to touch the following files:

bus.html – has the structure of the page in it. Only addition to the “original” model was the addition at the bottom of it:

<link rel="stylesheet" type="text/css"
    href="/dev/_skins/bus/css/page.css"
/>

It loads the page/site/skin specific skin late in the cascade. More on this matter later.

page.css – the content of this sheet is modest as well – since all we want to do is add a logo:

#sitetitle{
    background: url("../images/logo.png") no-repeat scroll right top transparent;
    padding: 10px 310px 0px 10px;
    min-height: 50px;
    text-align:left;
    vertical-align:middle;
}

The 2 images in the images folder are the logo.png that this site will be graced with and a thumbnail thumb.png that will be used as a link so that this theme can be picked by the user. Another image in the root folder is prev.png. This is an image sized to 520 × 366 approximately that will show when a user picks this theme in the theme picking panel. I used a screen shot of the finished page for that, then re sized it.

After I was satisfied with the modest page/site/space skin, I duplicated the bus folder a few times, named the other 2 to match the paths I specified in dev/_configuration/config.js, and then edited the *.html files to point to the corresponding *.css, changed the images, and done.

Here is the theme picking panel showing the thumbnails and previews:

And here are cropped parts of the three themes. Click on the images to see a full sized version.

More soon on what all of this means.

Advertisements

Skinnin’

August 23, 2010

Skinning involves an entity reformatting a bundle of functionality to make the experience of that functionality reflect it’s sense of self. When the entity is a simple one like a single human user, the task is a simple one as well. When the entity is a complex one with different parts that demand representation in the interface, things can get complicated.

I) A skinning system needs to account for different user spaces

  1. Institutional Gateway – traditionally has family resemblance to other institutional spaces. May have to obey institutional web style guides (logos, palettes, fonts)
  2. Personal spaces – can have an a) institutional branding as 1 above, b) a sub-institutional branding depending on affiliation (College of Life Sciences branding) or c) self selection (“cool dude” branding) – these are in descending order of probability, ascending order of complexity (and narcissism).
    Personal spaces are any space that is restricted to just one user: spaces that index one of the following: 1) other spaces, 2) activity that takes place in other spaces, 3) spaceless activity that is meaningful to the user because of user’s relationship to that activity. Also any space where the user changes the dynamics of her relationship to the system: ie – changing one’s profile, notification options, etc.
  3. Shared spaces
    Any space that is not private to one user *and* needs branding by virtue of what the space functionally is. Can have 1) institutional branding, 2) affiliation (Life Sciences) branding, 3) cascading affiliation (Life Sciences > Entomology) branding; 4) space type specific branding [a) t&l, b) research, c) club, ad hoc]. There is a cascade involved in that branding closest to the root determines branding unless lower nodes specifically override parts or all of the branding elements. How the cascade works in practice is left to the institution’s best judgement and restraint – but the ability needs to be there, it is important to the sense of self of the institution and it’s subunits.

II) A skinning system needs to account for different functional locales

A given functionality has unique rendering needs that it takes care of itself. All non specific needs are taken care of by skinning system. Widget A is very unique and has unique needs, but the UI idioms it shares with the rest are shared (Save button is blue and flush left, for example)

III) A skinning system needs to be easy to customize

  1. enable and encourage customizations via a canonical mechanism, allow customizations via other means (but not facilitate them or even account for them, an institution should be aware of the risks involved)
  2. common locales and procedures to customize should be provided, named appropriately, with a clear and documented cascade.

V) A skinning system needs to hint at what elements can best be skinned and to what degree it is recommended they be skinned. The institution can do as it pleases – but probably would appreciate the help and guidance.

VI) A skinning system needs to account for special user needs

A user should be able to override any and all skin definitions because of low vision, poor eyesight, color blindness, other factors. This has two facets: the skinning system should not trump user stylesheets (if that is how the system has chosen to deal with this issue), or the skinning system needs to provide a set of alternates, and the user choice of the system alternate is part of the user’s preferences.


Skinning the Sakai 3 gateway

August 20, 2010

I took a long look at the Sakai 3 skinning architecture before the Denver conference and came to a set of conclusions. The most important conclusion was that this was not the time for conclusions, as the target was moving too fast.

Maybe now is the time to explore. As an experiment I pretended to be someone charged to change the gateway (and only the gateway). An effort was made to not even “think” about what would be the ideal process – but just to get the job done.

The results can be sen here and if that poor old tired seven year old Dell is down, in this screenshot

For the curious, the process is detailed below. The good news is that it took a about an hour (it shows!) and it would have taken less time if I actually knew how to use Photoshop and Illustrator. The bad news is that on reflection the path I took (out of ignorance or because it was the only path) was not optimal. More on this later.

dev/_css/sakai/sakai.index.css

Change watery background image to city scape

html {
  background: #093b52 url(../../_images/cityscape.jpg) top left repeat-x;
}

Hide header byline

.header-byline {
  display:none
}

Hide Sakai logo

.header-title img {
  display:none
}

Display an alternate banner via .header-title (adjusting width, height, padding and margins)

.header-title {
  color: #08415E;
  width:650px;
  font-size: 4.0em;
  float: left;
  margin: 25px 35px 25px 0;
  padding: 40px 0;
  background:url(../../_images/header-title-back.png) top left no-repeat
}

The “Register here” link is defined in this sheet as well, instead of in a global/core sheet

#register_here a {
  color: #000000;
  text-decoration: underline;
  font-weight: bold;
}

dev/index.html

The thumbnail is hardwired in the markup.

<img src="_images/panel_thumb.jpg" alt="__MSG__INSTANCE_NAME__" />

So either change the source, overwrite the image with a new one, or hide it and add a background to the container (.preview-box). Chose to change in the markup

<img src="_images/cityscape_panel_thumb.jpg" alt="__MSG__INSTANCE_NAME__" />

I also found I needed an additional canvas. For a zombie, sure, but it could have been a panel representing the institutional image of self, so added as a direct child of the body:

<div id="zombie"></div>

dev/_css/sakai/sakai.base.css

The background for all pages (other than index.html) is here

html {
  background: #75ADD7 url('../../_images/cityscape.jpg') top left repeat-x;
  font-family: Arial, Helvetica, sans-serif;
  line-height: 120%;
}

“Sign in” button of the gateway: like all buttons – depends on a sprite (retrieved from a common non-skinned context) applied and positioned in an outer and inner elements, changing the sprite may need a change of color of text.  The sprite is here:

dev/_images/button-sprite-5state.png

Changing the colors in the sprite might also entail changing the text color for the caption in the .s3d-button selector.

I left the buttons alone in this experiment.

footer files

Note: background of footer is a composite of inline CSS set in 1) devwidgets/footer/javascript/footer.js; 2) image background set in devwidgets/footer/css/footer.css and 3) background color in devwidgets/footer/css/footer.css

I left the footer alone in this experiment, except for the logo and links:

.sakai-footer .fixed-container img {
  display:none;
}
.sakai-footer .fixed-container a {
  color: #fff;
  text-decoration:underline;
}