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.

The tool navigation:

And an actual tool:

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).

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

And what the Sakai skin looks like:

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.

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;
}

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.