New Gateway

June 5, 2013

At Michigan we were inspired by Duke (https://sakai.duke.edu) to replace the standard Sakai !gateway site with a custom one. We considered Drupal as a front end briefly, but eventually settled on a custom page served via Apache from the  Sakai /library webapp. We may revisit this decision.

The requirements were just three: it should be easy to update by content specialists (and not require a build), it should adapt to smaller screens, it should be fairly lightweight.  Additionally would need work on the portal to redirect anon and logged out users to this page (thanks to Patrick Haggood  UMICH-594 and SAK-22991).

Here is the end result.

Screen Shot 2013-04-10 at 8.10.52 AM

  1. This is a carousel (adapted from http://www.agilecarousel.com/) that was fairly light weight, fairly accessible and easily extensible to function via Entity Broker feeds from the announcements of a special “Gateway Admin” site.  The Announcements tool has a set of templates that the communications team uses to create the messages.
  2. This is reserved for important system announcements. Normally it is grey and boring – but if there happens to be a visible HTML resource at a specified location in the “Gateway Admin” site it will show that and the background will go to a defcon3 yellow.
  3. This is a rolling Qualtrix poll managed by Steve Lonn.  The iframe points to a document in the /Public folder of the !admin site that he edits whenever he needs to change to a new poll. Not ideal and way too much iframe resizing, but it was the easiest way to put control of the content where it belonged.

Screen Shot 2013-04-10 at 8.38.54 AM
Last – the same simple page adapts to small devices: this is done via @media queries.  Future work should do something more reasonable. As it stands mobile users are downloading content they are not seeing.

In the future it would be good to also point all the content areas (“New to CTools”, “Helpful links” etc.)  to resources in the “Gateway Admin” site so that they can be changed as needed on the fly.

The source for this is at:

https://source.sakaiproject.org/svn/msub/umich.edu/ctools/ctools-reference/branches/2.9.x/library/src/webapp/gateway/

and the URL is: https://ctools.umich.edu/gateway/

Advertisements

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.


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?


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.


The Sakai PDA portal

November 20, 2008

Sakai has a portal for small devices since 2.4. It is pretty bare bones but it does several neat things:

  1. it flattens the tool/site hierarchy so that they can coexist in the same breadcrumb
  2. it serves up an iframeless experience
  3. it elides many elements from the portal that would be noise in a small screen

Am working on several improvements to it for Sakai 2.7  under SAK-14827 and we are testing it at Michigan. It has been a very instructive experience constraining things to the small screen. What follows is a description of the changes, some tools and techniques that were useful, and some  observations from the preliminary testing.

The main tool turned out to be an iTouch that Chuck Severance donated to the lab. I tried several emulators such as iPhoney, Apple’s iPhone Simulator that comes with the iPhone SDK but there was no substitute for the actual thing.

Initially all I had in mind was polishing the portal, taking into account the screen size and the input device (your finger!). The PDA portal is served via a single Velocity template file present at a specific URL, so there was no need to do device detection – if you are there, you are using  a PDA (or, if you want to use a PDA you should use that URL). In the future it would be nice to route that  user agent to that URL automatically.

http://localhost:8080/portal/pda

The main complication was setting the viewport via the <meta /> tag. The official documentation is very telegraphic, but there is discussion about it. Eventually I settled on the following:

<meta name="viewport" content="width=device-width,
     user-scalable=yes,  initial-scale=1.0, maximum-scale=2.0"/>

The main issue here is font sizing after an portrait/landscape orientation change or after the user input zoom function takes place. Amazing to think that some people are using Javascript to detect the first.

The second task was to take all the styling references out of the template and out of the experimental portalstyles.css and create a CSS framework for the PDA. This entailed adding a pda.css + 3 images to each skin in the system, and querying in the template what was the skin in use per site.

Note: I have only checked into trunk the style sheets and images. The changes to the velocity template (pda.vm) and loginTool.java are being reviewed.

Now that the PDA portal was skinnable, it’s styles could be addressed via the CSS. The main preoccupations here were the following:

  1. font sizing
  2. adjusting padding/margins on links so that fingers of a moderate fatness could poke in the right place…
  3. curtailing horizontal spread

The results for the gateway pages and the site/tool pages are pretty good. Below with the University of Michigan skin, site navigation.

picture-3

The tool navigation:

picture-41

And an actual tool:

picture-1

I have craftily selected a tool for the screen-shot that works very well in this medium: the calendar summary from the excellent folks at Universidade Fernando Pessoa. Other tools are less fortunate.

A fun thing was adding icons for bookmarks. Following this tutorial I created a handful in no time. The iPhone actually takes care of all the glitz effects (corners, glassy look).

picture-5

And this is what the icon looks like in the “desktop”

picture-7

And what the Sakai skin looks like:

picture-8

Preliminary testing with the iTouch indicates some problem areas.

  1. Any tool that uses internal iframes is hosed.
  2. The browser detection identifies the iTouch as Safari, and serves it the default rich text editor, with it is unable to use – it should instead serve a plain text area.
  3. Cannot do attachments because the <input type=”file” /> is disabled in the iTouch.
  4. Not all tools render nicely, lots more to be done in this area.

RTL’g Sakai Tools

October 22, 2008

In order to create a skin for a RTL context we will be working in a the tool.css (so that we can override tool_base.css) of a new skin, named RTL. We will identify changes that need to be made, workarounds, failures to account for an RTL context in the tool design, etc.

If you are not very interested in the details  – the uncombed and disreputable skin is availiable here

If you want to know how we got to this and the shortcomings of this approach, read on.

We will begin with a simple tool view  – the Announcements list. What it looks like in a LTR context:

What the direction:rtl applied to .portletBody gets us. Am keeping the language as English.

Some nice things: the toolbar has been rearranged. The columns of the announcement table have been flipped correctly. Block elements are now flush right, such as the <h3>Announcements</h3>. The label of the view navigator select is not to the right of the select. The select itself is reoriented. The list paged lists, from right to left: “first page, previous page, next page, last page” correctly as the entire block has been flipped.

Some things that will need to be addressed: a) the pipes between the toolbar items look wacky and need to be aligned right; 2) the navigation panels need to be flipped ( a sad irony: if the layout of these and the toolbar  had been a table our work would be done); 3) the text direction of the cells inside the table needs to be adjusted.

The toolbar

Align the toolbar right. We will be working in the new rtl/tool.css):

.navIntraTool {
	text-align: right;
}

Add a border to the span child of the first list element:

}
/*special style for the first item, namely no border-left*/
.navIntraTool li.firstToolBarItem span{
	/*border:none;*/border-left:1px solid #ccc;
}

and take the border away from the last:

.navIntraTool li:last-child span{
	border:none
}

Since the design of the toolbar did not take into account a RTL possibility we had to resort to a pseudo class to identify the last element. We will see this problem elsewhere.

The navigation panels

The layout of these is set in tool_base.css. We will override in rtl/tool.css:

.viewNav{
	float: right;
}
.listNav{
	float: left;
}

The table list

/*skinned header of standard tab. data table*/
.listHier th, .listHier td{
	text-align: right !important;
}

The !important is needed to override the !important in tool_base.css – a bad decision that now needs to be dealt with.

The end result:

And in the target language:

Some issues remain with the navigation panels – reversing the floats did not exactly reverse the position, resulting in some inexplicable whitespace.  Someone help, please.

To recapitulate before we take on a more complex view of this tool: a) any series that identifies a first item also needs to identify the last; b) floats are not always totally reversible.

Forms and inputs

Some problems regarding the layout of the input, label and required marker troika. The orientation of the three is just not working due to floats. An example from create a new announcement.

So we rearrange the floats and display attributes, paddings, margins (if you are redoing an existing skin, look for some of these definitions elsewhere in the sheets if your results do not match):

.shorttext label{
	float:none;
	display:block;
	padding:0;
	margin:0;
}
.shorttext .reqStar{
	float:right;
	margin-right:-7px;
}
.longtext label{
	float:none;
	display:block
}
.longtext label .reqStar{
	float:right;
	margin-right:-7px;
}

So:

And in Arabic:

The other input types render correctly without any tweaking (this is also from create a new announcement):

While on the subject of inputs, the following is also needed if there is to be mixed RTL and LTR content:

input, textarea{
	unicode-bidi: override;
}
This opens an  additional level of embedding and overrides the Unicode character ordering, reordering the sequence to the value of the direction property. 

A quick glance over the core tools and it seems most rendering now is OK. There will be exceptions where the developer has been forced to apply sui generis layout or styles because of the paucity of the default styles. There will also need to be addressed – please leave some comments where that is the case, thanks!

Off hand – here are some locales that need more work because of these and other reasons:

  1. Filtering controls in Schedule list view.
  2. “Add” menu in Resources – text is misaligned.
  3. Certain icons are facing in the wrong direction – such as disclosure triangles. These will need to be replaced in the file system when they are inline images, or in the skin when pulled as background images.
  4. The FCK Editor – needs configuration – information on configuring the FCK Editor for RTL is here. There are language files for Arabic and Hebrew, Persian as well. Probably a lot of other stuff that a native speaker could figure out needs to be tweaked.
  5. Placement of icons inside certain blocks needs to be tweaked – see alertMessage etc. 

The uncombed and disreputable skin is avaliable here.