Page Comparison

jQM and Fluid

Reasons to Use jQuery Mobile

• Potential to become a popular project with a large user base
• Great functionality
• Support for a number of browsers, including non-webkit browsers
• Ease of development
• Accessibility

Potential Technical Hurdles

• JavaScript initialization: document.ready
• Fluid Renderer
  • Initialization
  • Elision
• Including multiple versions of jQuery Mobile
• Navigation
• data-theme

Strategies

Configure portlets to use portal's Javascript dependencies

...

Mobile Frameworks

About Fluid Mobile Skinning System (mFSS)

mFSS provides a pure CSS mobile skinning framework for webkit-based browsers (including those bundled by the iPhone and Android). mFSS is used in the uPortal 3.2.x mobile theme, as well as a number of Jasig portlets' mobile views.

About jQuery Mobile (jQM)

jQuery Mobile is the current evolution of the jQTouch project and is currently (as of Feb 2011) in alpha release status. The project offers a mobile skinning framework that supports a large number of browsers, as well as additional mobile-specific features like touch events and AJAX page transitions. jQM's documentation doubles as a demonstration of the framework and can be found at http://jquerymobile.com/test/.

Comparing jQM and mFSS

jQuery Mobile is genrally a much more heavy-weight, JavaScript-intensive framework that mFSS. While mFSS performs skinning based solely on a set of well-defined CSS classes, jQM requires developers to place custom attributes on elements, which are later parsed and "enhanced" by the JavaScript library.

This enhancement strategy means that original markup is small, easily readable, and easy to write, but also means that the framework is heavily dependent on javascript and that the final markup differs significantly from the original written markup. This strategy may cause problems for low-bandwidth mobile users, as well as creates some problems with using the Fluid renderer.

While uPortal might prefer a less-heavyweight solution, jQM appears to be a fairly high-quality project that's likely to become a widely-adopted mobile platform. It offers a number of features that are attractive to uPortal, including support for a wide variety of mobile browsers, nice mobile styles, and mobile events. At this point, uPortal needs a number of features this framework offers and should probably adopt at least some pieces of jQM.

Fluid has stated an intention to work with and complement jQM rather that competing with it. Jen Bourey is currently hopeful that uPortal can adopt the best parts of jQM, benefit in the immediate term from easy skinning resources, but continue to work with Fluid for a more balanced long-term solution.

Potential Technical Hurdles

Fluid Renderer

Using the Fluid renderer alongside of jQM appears to present some particular challenges. jQM parses the DOM to determine the roles of various elements, then adds additional divs, spans, and other wrappers, and applies CSS classes to both old and new elements. This process means that the markup originally included in the page is not the markup ultimately presented.

The Fluid renderer uses sample markup as a template for rendering data. In initial experiments, it appears possible to use the Fluid renderer alongside jQM as long as the Fluid renderer is initialized after jQM parses and enhances the DOM. Most renderer/pager code seems to work reasonably well with this approach, but we've identified several potential issues for some content.

Tab Index

jQM helpfully applies tabindex attributes to elements like navigation list elements. While this seems like a terrific accessibility enhancement, the Fluid renderer will use that initial markup as a template, eventually resulting in each member of the list having the same tabindex of zero. Mobile code using the renderer may need to manually apply the tabindex to each element.

Elision

Fluid's strategy for including a repeating section of two components involves using the "elision" syntax. For example, we might have:

<ul rsf:id="container">
    <div rsf:id="~repeatingNode:">
        <li rsf:id="part1">Part 1</li>
        <li rsf:id="part2">Part 2</li>
    </div>
<ul>

<ul>
    <li>A: Part 1</li>
    <li>A: Part 2</li>
    <li>B: Part 1</li>
    <li>B: Part 2</li>
    <li>C: Part 1</li>
    <li>C: Part 2</li>
<ul>

While this syntax works quite well in the absence of jQM, we cannot rely on jQM to properly parse and enhance the above example. jQM is confused by the div wrapping the list elements, and simply refuses to render any contents for the list.

We can achieve moderate success by omitting data-role attributes from the markup and instead manually applying expected CSS classes. Some of the potential problems with this approach will be discussed later in the strategies section.

Including multiple versions of jQuery Mobile

uPortal currently take care to allow adopters to include multiple versions of jQuery in the same page. The uPortal theme, as well as each portlet, are expected to use jQuery in extreme noConflict mode, such that each portlet scopes its version of jQuery, as well as other libraries, to a single window-visible variable.

This strategy has been quite successful and has allowed uPortal adopters to freely mix and match portlets with various uPotal versions. If at all possible, uPortal would like to continue to allow adopters to upgrade uPortal and portlets independently of each other, and would like to avoid needing to maintain a separate view for each version of jQuery.

jQM is not 100% compatible with Jasig's general strategy. In particular, the markup parsing and enhancement can necessarily only be applied once to the page. However, it does appear that it is possible to suppress parsing and enhancement for subsequent jQM includes, and it appears that when following our JS library inclusion strategy mobile events work with multiple included libraries.

<script type="text/javascript" src="<rs:resourceURL value="/rs/jquery/1.5/jquery-1.5.js"/>"></script>
<script type="text/javascript">
  $("[data-role=page]").live('pagebeforecreate',function(event){
    return false;
  });
</script>
<script type="text/javascript" src="<rs:resourceURL value="/rs/jquery-mobile/1.0a3/jquery.mobile-1.0a3.js"/>"></script>
<script type="text/javascript">
  var ${n} = {};
  ${n}.jQuery = jQuery.noConflict(true);

  // custom portlet script using ${n}.jQuery

</script>

Theming

jQM has a somewhat different theme strategy from jQuery UI and other theming frameworks uPortal has used. Each jQuery theme contains a number of "swatches" (five in the default theme), which are ordered by visual importance. By default, the theme framework uses c as the baseline, a for important elements like headers and footers, and e for subtle accents. To style elements in the page, developers are instructed to place a "data-theme" attribute on the element or section to be styled differently from the default.

While the jQM themes are attractive and the system isn't difficult to use, the general strategy doesn't seem particularly ideal for portal use. All portlet developers would have to agree on the swatch letters to associate with various portlet components, and it might be difficult to achieve a standard look.

It might be wise for uPortal to attempt to do away with the swatch strategy, instead associating swatch colors with the portlet CSS names currently being donated to Fluid. For example, jQM recommends theming cancel and save buttons differently by using different swatches. uPortal might instead prefer to preserve the "primary" and "secondary" button CSS class names and associate swatch colors with those, since these CSS names are more semantic, easier to standardize on, and are already in use in uPortal. Similarly, we might prefer to re-use the portlet name CSS classes rather than using a non-default swatch level for portlet-specific navigation bars.

Navigation

jQM includes capabilities for AJAX navigation and performs attractive swipe-style animation when loading new pages via AJAX. As attractive as this feature is, AJAX navigation appears to be complex and likely will particularly poorly with uPortal 3.2's URL syntax. Jen Bourey recommends shelving AJAX navigation for the initial mobile effort and re-visiting this as a 3.3+-only issue at a later date.