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-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?

Advertisements

12 Responses to Sakai Mobile Portal

  1. Very nice work – thanks. My favourite bit is how you show/hide columns based on the kind of browser the user is using. The nice thing is that this a nearly a pure CSS solution and did not require deep modifications to the tools themselves. Nice.

  2. gonzalosilverio says:

    Thanks – it is very liberating to be able to target a specific browser and screen size this way. The tools affected are just an example. More can be done.

  3. Daniel Merino says:

    Hi, Gonzalo.

    These are really great changes and we are fairly interested in them. It’s a sorrow that it has been merged into 2.7.2, because we are currently using 2.7.1.

    Do you think that all these patches could be applied in a 2.7.1 version without danger?

    Thanks in advance.
    Best regards.

  4. gonzalosilverio says:

    Daniel,

    I do not see why, if this has made it into 2.7.2, it cannot also be merged with a 2.7.1 installation. Let me know how it goes. There are a lot of changes, from big ones like the portal and WURFL stuff, to small ones.

    At Michigan we have also taken things one step further, see SAK-19955, SAK-20035, SAK-20179, SAK-19640, SAK-20330, SAK-20332, UMICH-330, UMICH-334, UMICH-372, UMICH-359. Not sure if all of these made it to 2.7.2. The crucial ones are SAK-20035 from Chuck and all of the ones that disable the RT Editor, mostly from Zhen, but still trickling in for some tools.

    Best, Gonzalo

  5. Daniel Merino says:

    Hi, Gonzalo.

    I have tried almost all the patches you recommended to me and it has gone quite well. Thanks a lot.

    The only issue I can see is that FCKEditor is disabled when user connects from a mobile device, and this includes iPads. However, the classic view works fine at iPad and users choose it as soon as they notice it. This makes the FCKEditor appears again, so they can’t write in it.

    In my opinion, FCKEditor should be always disabled whenever the user-agent is one of either iPhone or iPad, no matter what view is shown. Do you think that I should write a comment about this in SAK-18098?

  6. Daniel Merino says:

    Hi, again. It seems that cache has tricked me and the FCKEditor is not loaded in the classic view when an iPad is used.

    Best regards.

  7. Thomas Amsler says:

    Great work!!

    Are there any plans to use one of the mobile frameworks such as JQueryMobile, UCLA’s MWF, etc.?

  8. Susan Takpi says:

    Does anyone know where i can find a full list of sakai features available via Mobile Portal such as iphone and or blackberry. Also if you know the best phones to use to get the best from the Sakai features available. Thanks

  9. gonzalosilverio says:

    Hey Susan,

    I think this would be a great bit of data to have (what phones, what features). I think if you post this query in the sakai-dev@collab.sakaiproject.org list we could all benefit from the answers.

  10. I’ve been browsing online more than three hours today, yet I never found any interesting article like
    yours. It’s pretty worth enough for me. In my opinion, if all website owners and bloggers made good content as you did, the web will be a lot more useful
    than ever before.

  11. Lucie says:

    Skype has launched its web-structured customer beta to the world, soon after establishing
    it broadly inside the United states and You.K.
    earlier this four weeks. Skype for Web also now supports
    Linux and Chromebook for instant online messaging interaction (no
    video and voice but, those call for a plug-in installation).

    The increase of the beta brings assistance for a longer set of languages to
    help you bolster that international usability

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: