As part of our effort to develop our mobile offerings for HPI and other applications, we took a detailed look at a number of different frameworks during our TSG sponsored Hack Day. This post will present our findings.
Native versus Web Applications
One of the major decisions for development was whether to go with a native application for a specific device (ex: iPhone or Android) or simply use a mobile browser. Native applications have full access to device specific goodies and APIs that allow developers to create rich mobile applications, just like in the desktop world. A couple of downsides to the native application approach include:
- Difficulty in supporting all the different types of devices consistently – Our clients have a variety of devices (ex: iOS, Android, Windows Mobile, and Blackberry OS) and we were concerned about having to dedicate developers to each platform to deploy a consistent application.
- Difficulty in updating/releasing – All mobile native applications are subject to the individual systems approval and release. (iTunes, Android Market, etc). As a native application, the vendor wants to make sure that the application will not affect other components of the device. This can present an issue with timing of releases (pending approval) as well as requiring the user to upgrade the release.
We found that, for the bulk of the services we were looking to provide for ECM customers, the HTML5 browser approach was much more desirable than building multiple native applications. We think HTML5 and Javascript are here to stay and can be used to create the same applications that could be created natively with some significant benefits including:
- Support of different devices was addressed through the browser and consistent standards. We feel strongly that the mobile browser platforms are rapidly developing (Google, Facebook….) and will continue to evolve across vendors with open standards.
- Changes could be released quickly without vendor involvement or requiring the user to upgrade the application on their device.
- The majority of the UI’s being used for mobile applications for ECM can be easily created with HTML/CSS, and when necessary, the HTML5 canvas can be leveraged for amazing graphics. Search and retrieve and approval of documents does not require an “Angry Birds” interface.
Mobile Web Application Frameworks – HTML5 Approach
One issue we discovered with some of the frameworks is that the current offerings seemed to ignore the fact that mobile devices are less powerful than modern desktops, and seem to start with an existing desktop javascript library which is then customized for mobile devices. This approach tends to lead to long startup and load times for applications, even though the application typically will only use a fraction of the framework. We found this true in particular with the HTML markup used with some of these frameworks that was extremely heavy and unwieldy. We thought this heavy layer would lead to issues with UI customization and performance issues.
After reviewing Sencha Touch and jQuery Mobile on a wide variety of Blackberry 6/7, iOS devices, and various Android devices, while great for quick prototypes, it seems clear that these frameworks are built for iOS and “support” the others because of their use of a WebKit browser. We also found that mobile browsers are actually just as annoying as their desktop equivalents as there doesn’t seem to be much consistency yet. See related link for additional detail: http://www.quirksmode.org/mobile/viewports2.html
jQMobi and knockout.js– a different approach
We recently found jQMobi: http://jqmobi.com/ and it definitely follows the pattern we’ve come to love from desktop jQuery. Instead of starting with all of jQuery from the desktop library, jqMobi provides the equivalent features, but has removed many of the components that would cause performance issues. In addition, simple plug-ins are included to cleanly deal with mobile events and gestures. As with any of the frameworks we’ve tested, we’ve run into issues as we deviate from the out of box examples. Unlike the other frameworks, instead of being stuck in a markup nightmare and having thousands of lines of script to look over, we wrote the markup and can easily tweak it for whichever device is not behaving properly.
TSG has recently been leveraging knockout.js: http://knockoutjs.com/ to build Rich User Interfaces. This framework allows us to write the direct layout, while providing solid MVVM concepts. Since we’ve been working with HTML/CSS/Javascript for so long, it is only natural to continue using it for our mobile applications. By combining knockout.js + jqMobi, we’ve got the proper library for accessing the DOM quickly and efficiently while completely separating our views for each device. Since we’re always working with javascript objects, our backends never care that a mobile device or desktop device is being used.
As of the date of this blog post, we are committing ourselves to begin offering many of our applications utilizing jQMobi and knockout.js. Look for updates soon in regards to Search/Retrieval as well as Approval for HPI.
Please comment below if you have any experience or other thoughts worth sharing.
Hi, would you also be able to shed some light on the backend integration architecture e.g. How would the mobile version of hpi connect to Documentum or Alfresco behind the corporate firewall?
Paras – great question. We have talked about VPN connectivity for firewall access but we would anticipate that the bulk of the access would be via the cloud. Take a look at the approach leveraging OpenMigrate to handle the firewall issues in the following post
https://www.tsgrp.com/2012/02/28/documentum-mobile-and-the-cloud-for-third-party-and-remote-approval/
Dave
Hi Dave
Thanks for the reference
would you consider using web-services (RESTful) as the middleware similar to the centerstage architecture rather than publish data outside the firewall?
Regards
Paras
I think having an application server in the DMZ/Cloud that can access the docbase behind the firewall would be an alternative – whether that be by RESTful web services or other means. Clients have expressed concerns in that:
– that is access to internal systems from outside and security
– do I need a license for every third party user – every device…..
My two cents,
Dave
Hi Dave, is there a mobile port of the Google Web Toolkit that TSG evaluated as part of this exercise?
Paras,
We haven’t looked into the Google alternatives yet. Thanks for the input, will put it onto the R&D list.
Dave