Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

uMobile Phase 2

uMobile's phase 2 will consist of additional portlet development, feature enhancement, and bug fixes resulting in a uMobile server and native app 1.1 release.

Architecture Updates

Performance Improvements

Some portlets (particularly the calendar) need performance improvements. We could attempt to improve performance either by maintaining the current WebView-based approach and improving caching, or by transitioning this module to be a native module. In order to decide on an approach, we should first profile the loading behavior to determine whether the delay is due to network I/O or JavaScript parsing. If network I/O seems to be a bottleneck, we should determine how much improvement can be gained from setting ETags and cache headers.

If acceptable performance can be achieved through ETags and cache headers, uMobile could contribute to completing full JSR-286 cache support in the uPortal platform. If not, select modules like the calendar should be implemented as native modules that consume REST feeds from the portlet.

Link from Web-based to Native Modules

Some uMobile portlets need to link to native modules in the native app. For example, the courses portlet's link to a professor's contact information should link to the native directory module, while the course location should link to the native map module. This development item should cover working out a consistent strategy for native app link URLs and applying this strategy to the course and search portlets.

Android Button Integration

uMobile does not currently support the expected behavior for all button presses to the menu, search, back, etc. buttons. Implementing consistent handling for these buttons will improve the native experience offered to Android users.

Module Updates

Map

As of 1.0, the native map module allows users to search across campus locations, but does not offer a compelling way to browse locations. Adding tag/category information to the map data would allow the map interface to offer a browsing interface, and the map might additionally be enhanced by adding multi-campus support.

Features important for making the map module more competitive in the uMobile 1.1 release include:

  • Categories and browsing
  • Multi-campus support
  • Allow user to center map to geolocation
  • Tablet-specific UI

Courses

Alternate merged announcement view

Discussion at the Sakai conference indicated that some institutions would prefer a merged view of synoptic information for announcements, etc. While the current by-course view is valuable, we might add an alternate view that merges information from multiple courses.

LMS integration implementations

To make uMobile easily adoptable, the uMobile community should develop working implementations of the generic LMS connector for popular LMS systems suich as Sakai, Moodle, and Blackboard.

It would also be beneficial to implement the new uMobile search API in the courses portlet, allowing the portlet to report search results from implemented LMSs.

Directory

Contact download

uMobile users should be able to download directory contact information to their phone's local address book.

Tablet-specific UI

The directory's native interface would benefit from a tablet-specific UI that makes use of the additional available screen real estate.

Announcements/Notifications

uMobile is in need of a high-quality announcements and/or notifications portlet. Jasig does not currently offer such a portlet with a jQuery Mobile-based interface, though the Announcements Portlet might be a good starting point, as it already has a custom mobile interface. Alternatively, one of the in-development notifications portlets from a uPortal institution might be a good fit.

Additional Portlets

uMobile would benefit from the development of additional custom portlets that offer additional university-specific functionality and help uMobile compete with other platforms. High-priority portlets might include:

  • Dining Menus
  • Athletics
  • Computing Lab Availability

These portlets could be implemented using a strategy similar to the maps/courses portlets, in which the initial implementation offers the user interface, a generic API, and a default mock data implementation. Individual universities would be responsible for connecting the generic API to their custom data source.

  • No labels