best practices in informational smartphone apps
This is a summary of the paper that I am going to be delivering on Monday at MobiCASE organized by my dean at Carnegie Mellon Martin Griss. I’ll be showing a lot of examples there of good and bad native smartphone apps (putting all those pics in a blog post is probably not as effective). It is not an ad for Rhodes and RhoSync, although using them makes it MUCH easier to do most of these things. Interested in hearing your opinions on these issues, especially ahead of my talk on Monday.
Effective Informational Smartphone Apps
Usage of modern smartphones, as exemplified by recent powerful devices such as Apple’s iPhone and many different Android devices, has exploded recently. The usage on these devices is dominated by local native apps (versus mobile web pages). Over 6.5 billion apps have been downloaded from the iPhone App Store. There are over 200,000 apps on the iPhone App Store and more than 100,000 apps on the Android Market.
The success of local native apps over web apps raises some new questions in how to build optimal mobile apps. Most of the information technology industry has focused on how to best build web apps (mobile and otherwise) over the past 15 years. In effect these are truly centralized in their logic and information architecture. Local rich client native apps are a new development in the industry (or a resurgence of the truly distributed computing model). In either case it is worth examining how best to approach what, for most developers, is a new development problem.
Note that that we won’t be doing here however is making the case for native local mobile apps versus web apps. This paper assumes that the reader is already interested in building that native local mobile app.
For building native smartphone apps there are several guidelines emerging followed by the best smartphone apps. Most of these are quite distinct from best practices in either web apps, mobile or otherwise. It’s also worth noting that the guidelines here are really for informational smartphone apps (for enterprise or consumers) not for games, for which an entirely different set of best practices applies.
Context Sensitivity
Because of the latency necessary to navigate in mobile, it is best to take users directly to the most likely task that they may want to perform in the app. Given that an app can perform many tasks or manage multiple business objects, this “guess” of the appropriate task may or may not be correct. But getting it right most of the time will create a more usable app.
For example, a smartphone app for Customer Relationship Management could take the sales rep user right to the account that they wish to edit based on their location determined via GPS. An app can also take the user right back to the last screen that they used when the app was last used.
Avoid Typing
Modern smartphones are dominated by “soft” keyboards. And when they aren’t soft the keyboards are limited and small. The most usable apps use many clever techniques to minimize typing. There are many techniques available to do so:
- use far more select wheels and radio buttons than most web apps do, even at the cost of flexibility or more app data maintenance
- use the device’s knowledge of location for filling in geographic information
- use predictive text techniques such as Swype
Leverage Device Capabilities
Smartphones are more than small laptops. All modern smartphones ship with a wide array of “sense”: sight (the camera), “hearing” (microphone and voice phone connections), “touch” (as in touchscreen) and a sense of location in space (GPS). The best smartphone apps take advantage of these capabilities.
They make use of multitouch to zoom in and out, GPS to determine their location, use the camera to record images and videos, and integrate with other capabilities of the phone such as the phone dialer and the Contacts database.
Support All Devices
To reach the maximum potential user community, app developers need to be able to target all popular smartphones. There are a variety of techniques to building single apps that work on all smartphones. These include cross-platform frameworks which are burgeoning in popularity. Or developers can use the underlying SDKs for development (e.g. Objective C on iPhone) but use the browser component (e.g. the UIWebView control in the iPhone SDK) for rendering user interfaces.
Synchronized Local Data
If the app is an informational app, the best apps allow that information to be accessible whether or not the user is online. There should be some way of insuring that the necessary information is pulled down from any backend application servers, kept current based on changes and resynchronized back up to the central server when appropriate. Historically apps that only support “live data access” get far less usage, especially when the app supports creating, updating and deleting data.
Synchronization solutions can either rely on the device polling or some form of push solution. Polling-based sync drains device battery life and results in stale data. Push-based synchronization is better, and can now be done as modern smartphones now support push natively in the operating system (iPhone, Android and BlackBerry now all have native push capability).
Offline Usage
Beyond data synchronization (which allows offline usage of critical information) there is the general problem of making sure that apps can be used efficiently and completely when offline. Data synchronization solves part of the problem. In general however, the app should pay attention to make sure that the most important operations can all be performed whether or not the user is online. Not all apps insure this, but the best ones emphasize this ability.
Handle Varying Metadata
Perhaps the subtlest problem with the reemergence of truly distributed local applications running on modern smartphones is handling changes to the backend applications schema. With a web application when the data schema changes the application’s full stack is changed: the database, the business logic (usually in the form of a web applications controller) and the interface (the web app’s view).
With smartphone apps running locally on a remote device, its difficult for the central application developer (generally of a web app) to insure that all remote smartphone apps are updated. Thus there is usually a need for smartphone apps to handle changes in the underlying schema of the app or database that they connect to in a more sophisticated way.
This problem has been a big hindrance to the widespread availability of smartphone apps for enterprise applications on the smartphone “app stores”. The few developers that have been successful have handled this with some for of custom way to communicate metadata changes to the remote smartphone app. This is an area of emerging research and discovery among smartphone app developers.
Summary
In general smartphone app usage is rapidly expanding. There are a new set of emerging guidelines for how to build the best possible smartphone apps that app developers should carefully consider before building their app.
At Rhomobile we are committed to providing a framework that takes the best of modern web development techniques to attack the difficult problem of building great native smartphone apps for enterprises. What techniques have we left out here? What are other approaches to tackling these issues?
