Sakai 3 skins again

December 13, 2010

Responding to a message from Chris Roby to the Sakai Nakamura list, I took a test run through the process of tailoring the look and feel of Sakai 3 to match the branding needs of an institution and the results were  very gratifying. Very few lines needed in skins/default/skin.css (less than 60!) to produce something acceptable that represents the University of Michigan clearly and follows the institutional web style guides.  Only 4 new or modified images (that go in a new folder skins/default/images) were needed as well. Here is a screenshot.

Some possible improvements

1) skin CSS linked to too soon

skins/default/skin.css is linked to before other CSS styling canvases that could be considered important canvases for institutional skins – luckily these can be trumped in the skins css by ratcheting the specificity in skins/default/skin.css, ie: topnavigation.css is linked to after skins/default/skin.css and trumps the style for #general_search_container in skin.css unless one uses a contextual selector with more specificity: #topnavigationcontainer #general_search_container instead of #general_search_container

This is somewhat clumsy and not very obvious. Did not have to resort to !important but can see that happening if the later CSS selector is too specific to trump.

I notice for example that in the Wiki documentation !important is used to change the color of links – this is a symptom.

In other words: it may be a good idea to include skins/default/skin.css last.

2) side effects from overrides

There is a flash and jiggle of previous styles that is very apparent if the palette of skins/default/skin.css or the position of an element affected there is at variance with the values of any of the previous core selectors. This flash and jiggle is more pronounced if the connexion is slow or there is load or the sheets are not cached.

It may be a good idea to leave style “gaps” in the core sheets and supply a skin/example sheet that fills them in – this would accomplish several things:

  1. avoid possible flash and jiggle;
  2. identify clearly what are good skinnable canvases/targets;
  3. separate style concerns into core sheets (generic substance), skin sheets (institutional style);
  4. establish a sort of contract: “address the selectors in the skin/example and everything will be simple and you will not have to touch anything else probably,” reducing the task of the adopter to painting by numbers sort of.

3) facilitating broad strokes changes to match the institutional style guide.

Links are a good example that tend to spark a lot of controversy. One of the gaps in the core sheets may be link color and decoration. This would be addressed in the skin sheet, which would address the generic link (and the pseudo classes), and also the ones that are identified by class/id or context. This is very hard as everyone’s definition of what should be in the skin scope will be different. But identifying what a core set of skinnable possibilities will cover the majority of the cases.

4) increasing the scope of the core sheets and decreasing the scope of widget/page sheets

This would also be very helpful – specially since the widget sheets are loaded last – migrating all rules that should be generic to the core sheets would allow a skin sheet to affect anything it needs to affect with more ease (because it could trump core sheets without any skullduggery). I see this is happening  (SAKIII-1800, SAKIII-1803), which is great.  For example in order to eliminate the rounded corners in the main content area this was needed in the skin:

.header .fixed-container,
.header .fixed-container .decor,
.search-container .content_search .fixed-container,
.search-container .content_search .fixed-container .decor,
.account_preferences .header .fixed-container
  {
    background-image: none;
  }

Since it is the same graphic element anywhere it happens, it might best be served by a core sheet, once.

These points all revolve around separating core and page from skin, core and page from widget, skin from widget. 1) above is moot if we get the widgets out of the business of styling generic items best left to the core; 2 and 3 are moot if the core avoids declarations best left to the skin and so forth.

Advertisements

Sakai Mobile Portal

December 9, 2010

Since my last post on the Sakai portal for mobile devices a lot of features were added and many bugs addressed by the community. This is mainly a summary documenting the work done that is being merged to 2.7.x. My apologies if I forgot a JIRA/contributor, there were a lot of both!

Portal changes

The main change, that made the rest worthwhile and necessary, was using an updated WURFL to redirect mobile devices to the mobile portal  (SAK-18720 / Roldán Martinez, Horwitz, Swinsburg, Qian). This is controllable by a server property and is a huge leap forward!

The rest of the changes are below:

Give  users the chance to bail out of the mobile portal and going to full version (SAK-18800)

Fix some login issues (SAK-18955SAK-18768)

Fix JSR-168 tools in mobile portal (SAK-19060)

Links directly to tools/pages/on sites don’t work when portal autoforwards to PDA portal (SAK-18801)

Provide the ability to reset tools (SAK-14808)

Add the ability present in the full portal to insert arbitrary markup into a site’s mobile portal via a site property (SAK-19275) – this is useful in many ways, from adding Google Analytics to the Mobile gateway to adding any Javascript driven functionality to a given site.

Put all strings in bundle, fix scaling/orientation issues, sub-site link displays (SAK-19179)

Tool changes

Disable RT Editor and present a text-area instead for mobile devices (SAK-18098). This has the important side benefit that it removes an important accessibility barrier: the FCK Editor.  Screen reader users can use the mobile portal till the transition to the CK Editor takes place.

Detect inability to upload files in Resources tool for iOS devices (SAK-18711) and prevent subsequent errors

Skin changes

Fork the user experience three ways: 1) small mobile webkit (iPhone/iPod/Android), 2) iPad, 3) the rest. Provide a base for all user agents, a few small adjustments to the mobile portal and a few to the tools it encloses to size elements better for this medium (a lot of people contributed to this, but piles of thanks to Keli A. from Stanford).  Here is the tool menu in Firefox.

We used an @media selector for iPad to style links to fit in with iOS conventions and pad the toolbar links to help Zhen avoid hitting the iPad browser menu by mistake:

We used an @media selector for iPhone/iPod/Android browser:

To style toolbar, site and tool menu to fit in better with iOS conventions

In this format we omit from the breadcrumb unneeded information: the link to site list is the logo, link to tool list is the site name. If site name is too long it gets trimmed and an ellipsis is provided (in the toolbar crumb and in the site list). This is all very debatable – but there was just no earthly way of fitting it all (“Sites > Site name > Tool name”) in there otherwise. The trim is adjusted for orientation – horizontal gets more characters. Here is an example with a long site name:

Since the tool is in the same document as the portal in the mobile response – one can reach into frequently used tools and massage the display for small devices via pda.css. The initial Resources list view is unusable at an small size, but since we are dealing with a modern browser we can reach in and hide a few columns with some complex attribute selectors,  and trim and ellipse the resource title link based on device orientation (portrait / lanscape). Here is an example with Android:

It looks very busy still, but it is actually usable I think – although that remains to be tested. Here it is on a landscape orientation with an iPhone:

Announcements got similar treatment.

One of the gratifying things was to see decisions taken eons ago as to the structure of the interface elements bear fruit.  The liquid layout of form elements (from Ben Brophy, formerly of MIT, and Marc Brierly, Stanford) adjusts well to this format: the inputs drop under the label, neat!  Here is a screen shot of the create new user screen on Android:

Being able to affect tool rendering in the mobile portal  also had some other perhaps more questionable benefits. In some tools, because of use of iframes or other issues, some of the functionally was affected. In lieu of doing something sensible like fixing the tool, the pda.css hides the offending sector (in Chat it is the list of users that blows up and is hidden) or the opportunity to trigger the error (link to preview an edited page and link to create comments in Wiki).

The main work detailed above in the SAKs and the skin work has been merged to 2.7.x and our CTools branch (thanks again Zhen!) and we are testing the functionality in Michigan at the moment, including a stress test on the mobile portal itself.  Aside from uncovering more bugs we also hope to produce documentation that will rate the user experience of each of the tools (pleasant/root canal) for the guidance of our users.

Here it is in Android with the UM look (“ctools-int” is a dev server identifier string):

Naturally this falls way short of the experience of a native app, but at least the functionality is all (mostly) there now.  Maybe for Sakai 2.9 an expanded participation of tools in Entity Broker will foster a complete native app development following the Oxford example.

A question: we are assuming, perhaps wrongly, that covering iOS and the Android default browser will cover the lion’s share of our users. Do you have other suggestions?