My company built its own project management web application. It’s like basecamp on steroids. The core features of this application are:
- create task lists
- assign tasks to team members
- track hours against task items
I am looking to build mobile application(s) as an extension to the web application. The mobile applications(s) must:
- reproduce the features mentioned above
- connect to the same database as the web application
- retain drag drop capabilities
- provide a rich user experience equivalent to or better than the web application
- work on iphone, droid and blackberry
Given the requirements above, how should I approach the development of this mobile application? There’s about 20 smart phone users in my company: 8 iphones, 7 droids and 5 blackberries.
I’ve heard of development frameworks like Phonegap that allow you to develop in HTML, Javascript and CSS. The software then works cross platform across blackberry, iphone and droid. If I am an average/slightly-above-average programmer, will I be able to build a high quality cross platform mobile application with PhoneGap (or another x platform development framework) that meets the above requirements?
Or should I build each iphone, droid and blackberry application independently?
What’s the best approach? What are the trade offs?
John,
Well it sounds like you’ve got a bit of work ahead of you! When you have an existing web-based application, there are two basic approaches to getting your app available on any particular device: you can (1) write a native app that implements the functionality you want for each device you want to support or you can (2) write a web-based “wrapper” for your existing app and serve the content as HTML/CSS to those same devices.
Option 1: Build a native app for each platform you want to support
As for the first approach, the benefits can be great. By using each device’s native frameworks, you have the complete ability and flexibility to take advantage of the best features of each device. Your app’s views can also render faster, since all you will be fetching from your server is the data to populate the views with (i.e., you do not have to load images, HTML templates, or CSS files at all).
The drawback with this approach is that it inherently requires each device to have its own application. So if you’re supporting a web app, an iPhone app, an Android app, and a Blackberry app this means that you have 4 completely separate codebases to maintain. If you add some sort of new feature to your web app (which you presumably will at some point), you will also have to implement that new feature in the three other separate code bases. Given the fact that these devices can have different interaction models, this could pose a challenge. Another drawback here can be distribution (i.e., you may have to go through a review process for something like the iPhone app store depending on how you want to distribute your app). It also means that the amount you will have to learn is quite a bit greater since each device has its own API set and programming “philosophy”.
Option 2: Write a web-based “wrapper” for your app (perhaps using a library)
This approach also has a great deal of benefits. First off, if you use a framework like PhoneGap or Sencha Touch or Rhomobile, the big benefit is that you theoretically write the “mobile app” code once and it works across each of the devices supported by the framework. Compared to writing a native app for three platforms, this is a lot less work.
Downsides here are as follows. This approach runs as a website in the device’s browser, so you will not have access to all of the functionality of every device. All of the great stuff in the iOS and Android API’s will by definition not be available to you. You are also somewhat limited here with regard to local storage, but this may not be a great concern to you given your web app. Another drawback is that there will be more bandwidth required from your server this way, since you are serving all of the HTML, images, and CSS that you would otherwise not have to with a native app. Depending on the number of users and complexity of the pages, this could be significant to you or not. Another downside here is that you cannot go full-screen (with the iPhone in Mobile Safari for instance there is always a toolbar at the bottom).
General Concerns
One thing that concerned me reading your question was your list of requirements. Reproducing features and connecting to a remote data store are things you can definitely do with both native and web-based mobile apps. But “retain[ing] drag drop capabilities” is not. With an iPhone, for instance, you can use handles in a UITableViewCell to provide a way to reorder lists, but full-on drag-and-drop is not really something that fits with a mobile device’s user interaction model. You may have to re-think this one.
The requirement to “provide a rich user experience equivalent to or better than the web application” is also a bit troubling. While phone-based apps can have really streamlined ways to get at and manipulate data, remember that you are designing for a screen that is a few inches square. It is physically impossible to provide the same breadth of information in an organized manner than you can with a 21″ HD widescreen monitor.
Remember that you’re designing here for mobile, so you want to take advantage of the available platforms but remember that you’re dealing with small screens and limited interaction methods (touches, swipes, and gestures).
My recommendation is that if this is your first time at this, you want to support all of these devices, and you already have experience with the web, I would suggest taking Option 2 and using one of the above-mentioned frameworks. It would be the easiest way to start and there wouldn’t be any radically different concepts for you to have to learn.
Good luck!