Sakai Mobile Portal

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-18955,  SAK-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?

Advertisement