uPortal Mobile Support Initial Technical Analysis

This page covers plans for a post-3.2 next-generation mobile portal platform. At a high level, this work will involve updating uPortal's mobile theme, increasing mobile coverage among the Jasig portlet library, and creating native mobile device applications for uPortal.

Authentication

Current mobile application practices have primed users with the expectation that mobile apps should allow the user to sign in once, at which point credentials will be persisted and re-used until the user elects to sign out. Jasig needs to select a strategy for providing persistent portal authentication while accommodating potential needs for using Proxy CAS (n-tier delegated authentication, requiring that the solution support logging in via CAS) and CAS Clearpass (password replay, requiring that that login via CAS be via the end user's password).

It's important to note that the application should not require authentication and should offer a guest view to users who choose not to authenticate, or who do not have credentials.

At the current time, possible strategies for mobile authentication include:

Local Cached credentials

uPortal may elect to ask a user to enter his or her credentials into the mobile application, at which point they would be stored locally in the application's database or preferences. These cached credentials could later be posted to CAS, which could make them available to the portal via Clearpass. This solution would allow both CAS Clearpass and Proxy CAS usage, though it will require the user's credentials to be stored locally on the mobile device. For an initial prototype, this likely will be the best authentication solution, though uPortal may eventually need to implement an alternate authentication strategy for institutions which are not comfortable with storing credentials on mobile devices.

CAS OAuth

OAuth is a way for users to authenticate the mobile device authentication to CAS once via a CAS web interface and then for that delegated authentication to be remembered long-term.

uPortal could implement OAuth authentication to CAS, which would eliminate the requirement for storing credentials locally on the mobile device (significant advantage). However, this strategy would not allow for replaying the user's credentials via Clearpass (significant disadvantage).

CAS "remember me"

CAS provides a "remember me" module that allows users to repeatedly access CAS-protected applications without having to re-enter authentication credentials.

This solution involves greatly extending the duration in which Ticket Granting Tickets are valid. It has the technical advantages of working well in concert with ClearPass and requiring little or no custom development for this project.

However, a naive implementation would make "remember me" authentication available for traditional non-browser CAS authentication as well, which may not be desired on campus. The sophistication of the remember me feature and in particular support for advising and opting out specific relying applications is not currently great in CAS. Remember me as it exists today probably won't be really acceptable to many adopters.

That said, it will probably demo really well and be easy to implement.

Navigation

Mobile Browser vs. Mobile Application Presentation

uPortal must determine which parts of the mobile portal navigation should reside in the application itself, and which should be provided by the server's mobile theme. Developers should carefully consider the pros and cons of navigation placement to arrive at a solution that will feel native without tying the mobile application to specific portal version.

We must also determine a way to make any necessary theme changes for the mobile application presentation without breaking the presentation of the mobile theme to mobile browsers. If it turns out to be difficult to distinguish between mobile application and mobile browser accesses of the portal, we might consider using a request parameter at login time to differentiate mobile application sessions. This parameter could be used in a theme ? or possibly used by a modified profile selector.

While it will be more complex to move some of the navigation to the application itself, we may deem it necessary for presenting a compelling user experience (and may also prove important for getting the iPhone version of the application approved). Some developers believe application-based navigation may provide faster loading times, persistent navigation state, and more "native" looking presentation. Regardless of the navigation style chosen, uPortal may wish to make changes to make the presentation's navigation feel more native, such as locking some of the navigation to the top or bottom and allowing portlet content to scroll independent of those navigation bars.

Main Portlet Navigation

The most straightforward top-level navigation strategy would be to allow the portal to serve up the list of portlet links. This allows adopters to continue to customize the look and feel of the theme via the portal's theme and skin, as well as easily update it without requiring users to download new versions of the mobile application. It also ensures that the same version of the mobile application would work with multiple versions of uPortal, and prevents the portlet link implementation from being hard-coded into the application.

Some concern has been expressed that serving up the main navigation from the portal may not feel sufficiently native. This situation should be remedied somewhat by a recent bugfix in the mobile structure, but it remains true that users might experience a delay in loading times for the main navigation view under low bandwidth conditions. Some of this behavior might be improved by caching the main navigation screen.

Alternatively, we might consider providing the application with the layout structure via an XML document and allowing the application to render navigation itself. If the pilot pursues this sort of strategy, we would need to find a way to reliably link to portlets between user sessions.

Main Navigation Mockup

Portlet Display Mockup

Single Layout Constraint

While uPortal's profile support has been fixed such that users may have multiple profiles (mobile and desktop, in this case), uPortal still only supports one layout per user. Until this is fixed, the mobile and desktop versions must share the same overall layout and set of preferences. This constraint also in practice limits us to a mobile interface that does not offer layout editing.

This constraint is not intentional and is likely the result of this feature not being actively in the past. Fixing it would involve assigning an fname to layouts and ensuring that layouts do not depend on hard-coded numerical identifiers. We also might need to think through and fix the way some preferences are saved and applied, since anecdotal evidence suggests that some preferences may inappropriately be tied to the profile rather than the layout.

The code that controls layout selection and persistence is very old and pre-dates ORM, Spring JDBC, etc. This manual SQL code is hard to work with and very verbose. Fixing the multi-profile support was time-consuming and required the community to work through a large number of bugs. Because of this issue, the community has agreed that the multi-layout support issue won't be addressed until the user and layout support and database tables are refactored using JPA.

Given the current community roadmap, it seems like fixing this issue should not be considered as a phase 1 task for the uMobile project. We could work with the community to do this work prior to the JPA refactor, but it's worth noting that since this update will require database changes, it will only be possible to add as part of a major portal release. This work would likely require a large amount of time, which may also make it ineligible for phase 1 development.

If we decide we need to differentiate mobile and desktop versions, we can make use of the already-existing feature that can suppress certain portlets from the mobile device theme. We could also consider writing a DLM evaluator that considers the user agent or theme and push different fragments to the mobile device. We likely shouldn't consider either of these solutions as part of phase 1 development, since our initial mobile content isn't assumed to be also displaying a desktop view.

Someday when this issue is fixed, it would be nice to allow users to customize their mobile interface, potentially adding, removing, and reordering mobile portlets.

Other Application Links

Aside from the issue of layout navigation, it seems certain links are clear targets for integration into the application itself. Since this application will implement authentication via some sort of persistent strategy, links for signing in and out should be provided by the application itself. Search might also be integrated into the application, with the search being executed via a call to the search portlet's fname mode.

Map search might particularly benefit from being an application-based link, since this would make it much easier to launch an application-based native map.

Handling Special Links

Certain links and content within a portlet should be handled specially, similarly to the functionality demonstrated by the built-in Safari browser on the iPhone:

Persisting navigation state

It would be desirable to have the mobile application remember which portlet the user has last visited and to automatically open up to that location. To implement this feature, we might consider adding a javascript variable or something of the sort to the page to indicate navigation state, then configure the mobile applications to track this javascript variable for future use. Subsequent loads of the application could automatically request the current portlet's fname as part of the login string.

Badge Numbers

Many iPhone applications present some indicator of unread items both within the application and as a "badge number" visible on the application's icon. It would be particularly useful to be able to indicate the number of new announcements, email items, course notifications, etc. to users in order to invite them to interact with mobile portlets.

uPortal does not have functionality to display notification counts alongside portlet links out of the box. It's possible that we could devise some sort of API for representing the number of "new" items associated with a portlet and displaying those numbers in the main portlet navigation.

Maps

Yale has recently contributed the code used to power their Campus Map portlet to Jasig. This portlet is an add-on to the tabbed search portlet that allows users to search a Google Maps interface for both locally defined locations (lecture halls, dorms, libraries, etc.) and public Google Search API results (restaurants, etc.) As a result, a search for "library" in the Yale Maps portlet returns both Yale-managed campus libraries and city-owned public libraries.

This code should be added to the existing Jasig Search portlet, and the campus locations feed service should be updated to provide a standard JSON or XML format for campus locations. The locations should likely include at least the following information:

• Location Name
• Building Code
• Latitude and Longitude
• Picture

While it would be useful to simply have a mobile browser-based version of the maps portlet, such an application would not provide interesting features like walking navigation and allow interaction with the user's current location.

Campus maps might initially be assumed to contain no sensitive information, and thus not require any authentication. We might take whatever campus locations data service is developed for the main portlet and develop a mobile interface that uses the native device maps functionality.

LMS Integration

Jasig would like to develop an LMS integration portlet with a mock data store. We should look at past and present LMS integration portlets to gather data requirements and ideas for potential user interfaces. Portlets that should be considered include the Manchester-contributed Blackboard portlet, as well as the "Academus Enterprise" My Courses portlet. Simpler LMS integrations worth reviewing might include the WRI "My Courses" Moodle portlet, as well as Yale's Sakai integration portlet.

To facilitate integration, we have discussed developing a generic XML data representation containing a sample of useful course information. This XML data feed would have a well-written XSD and could be deserialized using JAXB. In the future, once the uPortal 3.3 release is available with JSR-286 support, Spring REST templates could be used with these JAXB mappings to further simplify the LMS portlet codebase. Care should be taken to produce useful, error-free interfaces from partial data sets, since LMSs may differ in the information they return.

Integration of a real LMS could consist of producing an appropriately-authenticated XML feed from the course system in question. For applications supporting CAS authentication, it would be preferable to perform authentication via Proxy CAS, although it would be possible to achieve authentication via credential replay if necessary. To promote integration, authentication should be wrapped up in an interface and be pluggable in the portlet's configuration. The Jasig calendar portlet may serve as a useful model for authentication for the LMS portlet.

To improve the initial pilot, we might consider creating an integration against the current stable release of Sakai. This integration would preferably be based on Proxy CAS and produce the expected LMS portlet XML. We may also want to look at the Manchester-contributed Blackboard portlet to determine whether it would be straightforward to produce an initial Blackboard integration as well.

Note that a stated requirement here isn't just that multiple course provider plugins be available, but that multiple such plugins can be used by a single instance of the portlet in concert. That is, we intend to scratch the itch of the school running multiple LMSs concurrently.

Apple-Specific Challenges

Apple's app approval process is notoriously difficult to navigate. Jasig must be aware that each adopting institution will have to apply for approval separately. Apple's guidelines state that applications must do more than simply provide functionality already built into the native browser, so any mobile portal application that simply wraps the existing uPortal mobile view stands a good chance of being denied approval. Functionality like native maps, address book integration, and persistent authentication might increase the chance of our mobile pilot being approved for the app store.

Futhermore, any iPhone-specific functionality (that is, functionality that's both device-based and specific to the iPhone) will likely have to be developed on a machine that is running OS X. This effectively constrains device programming for the iPhone to uPortal developers who happen to have purchased Apple laptops.