By Paul Golding
To Mobilize or not to Mobilize?
You’re a Micro-ISV and already have a product or service out there on the desktop or web. Now you’re thinking to take it mobile, but you’re new to the world of mobile apps. What should you be thinking about? In part 1 of this article, I’ll be looking at the general approaches to mobilization before discussing the technical issues in part 2.
Mobiles are exciting and there are many ways to exploit their potential for putting your products and services into the hands of mobile users. We needn’t labor the point too hard about the unique benefits of mobile, such as pervasiveness, but you should always start out by thinking carefully about how mobile can add value to your product before jumping on the mobile bandwagon. All too often, mobile apps flounder and don’t really enhance the basic offering. You have to weigh the benefits against the added drain on your already precious Micro-ISV resources.
But let’s say you’re ready to mobilize. What next?
Basic Mobilization Strategies
Firstly, think hard and long before potentially falling into the trap of only offering a mobile-only solution. It is extremely difficult to gain traction with mobile applications. Think of mobile as an extension to the desktop, not a replacement. That sounds obvious, but it’s a common mistake for some small start-ups. Plenty of developers think that they have a great idea for a mobile app and rush headlong into developing it only to run into huge frustrations with distribution. Leverage the web to garner interest in your product and use mobile to add value to your offering.
When mobilizing, there are generally two approaches to consider: what I call shrink-to-fit and umbilical cord.
Shrink-to-fit is offering a cut-down version of your basic desktop offering. An example would be the iPhone version of WordPress that only enables new blog posts to be written and posted, but none of the other blog management features. Such an approach is common and can work, but have realistic expectations of your users’ willingness to use cut-down apps in anger. Mobile usage is very pithy and intermittent and users are a lot less tolerant of the relatively limited UI.
Umbilical cord is more about thinking of ways to keep your user attached to your product. The most obvious is texting. Text alerts are easy to add to any web-based service, but an increasingly common approach is to add two-way texting in order to allow submission of content to the desktop application. Sticking with WordPress as an example, we could add a feature to allow blog ideas (e.g. titles for posts) to be submitted. Capturing ideas and ‘to-dos’ at the ‘speed of thought’ is a key way to exploit mobile because we always have a mobile to hand. A blog title texted to WordPress might cause a draft post to be created with that title, ready to be filled out when back at the desk. The mobile jotting application ThumbJot enables pithy jots to be submitted via text message, which is perhaps the quickest way to get something down using a mobile.
Another aspect to the umbilical approach is the data-drip. This means allowing users to gain a constant feed to their data whilst away from the desktop. With WordPress, this could mean a feed of the latest comments. Adding RSS feeds and mobilizing them is one way to do this. Email alerts will also work if your users have devices like the Blackberry or iPhone.
Of course, you might think that the umbilical cord will automatically lead to implementation of a cut-down version of your app anyway, so why not jump straight to the shrunk-to-fit option? This is a common assumption, but not necessarily a good one. Many users will be content with knowing what’s ‘going on’ with their data and be happy to revert back to desktop access to get the job done when they’re next at their desk. Moreover, the umbilical approach is generally a lot easier to implement and offers a means to test the water with your users before jumping in with a fully blown mobile development.
One final consideration is that umbilical and shrunk-to-fit obviously aren’t mutually exclusive. You can, and often should, deploy both approaches. One thing to keep in mind is that even with a beautifully implemented cut-down app, it’s no use if the user simply forgets to use it, which can easily happen on mobile devices where the app is buried away several clicks down in some menu option. Think about using alerts in order to exploit the ‘bump into effect‘ that will keep reminding your users to use the mobile options available to them.
Native or Web?
A common question is whether to implement a native app, such as a J2ME MIDlet, or to use the mobile browser? Don’t put the cart before the horse. Think long and hard about how the mobile will add value to your product and then act accordingly. This is where you really need to be self-critical and, as with all things Micro-ISV, make sure that the steps you’re taking are really going to add value to your product and likely to lead to more revenue. This is where seeking outside advice really helps. Put your mobile ideas down on paper and do some basic checks with trusted users or associates.
There are some basic checks to consider. For example, if offline operation is critical to what you’re trying to achieve by going mobile, then the mobile web isn’t really an option. If access to the device APIs, such as the camera or address book, is critical to your mobile ambitions, then you’ll have to go the native route. Hybrid solutions are also possible and some vendors have gone this way, putting key mobile functions in a native app and then offloading the remaining functions to the mobile web. The advantage is less native development, which can be costly and time-consuming, especially for a wide set of devices.
The fact is that it is easier to develop a mobile web app and it also leads to better device coverage. There are plenty of devices out there that have mobile browsers, which means potential users of your mobile offering. This might be true of devices that support Java MIDlets, but it won’t be long before you run into the grizzly problem of device fragmentation. Unless you’re using the very basic features of the MIDP set of APIs, you’ll find that your app is unlikely to work on all MIDP compatible devices in the way you might have expected.
However, if your solution can only be mobilized by the richer UI and API possibilities of a native app, then start off softly, which also goes for the mobile web option. Here there are a number of beta strategies to think about. Firstly, you can opt to develop only for a high end device, such as the iPhone, Blackberry or Nokia N95, giving the best possible mobile user experience. You can then see how users of these devices take to your offering before deciding how to broaden the offering, if at all. Get feedback. This is crucial. Make sure that you’re in touch with your mobile users and that you can measure how well things are going. With high-end devices it is easy to implement something that looks nice but has poor usability, so don’t jump to the wrong conclusions.
The second beta approach is to offer a lowest common denominator version that will work on the most popular devices in your market, which are obviously not the high-end devices. It is usually fairly easy to figure this out from research on the web. Don’t be afraid of offering a very basic UI for mobile if it does the job. If your mobile feature set really adds value to your overall proposition, then you might be surprised by how tolerant users are of something that is functional without all the eye candy of fancy mobile GUI widgets, whether native or on the web. In fact, if it’s the mobile web we’re talking about, then I would say that speed still trumps looks.
Going to Market
Can mobile be used as a means to market your application? This is a possibility. There’s a lot of interest in mobile applications, especially with devices like the iPhone. Therefore, offering an iPhone optimized version of your mobile web site, or even exploiting the iPhone SDK, will allow you to put your app into the various iPhone circles where it might get noticed, not least of which is the iPhone app store or the iPhone web directory. Getting a staff pick on the Apple site can bring a flurry of visitors to your site.
Many of the iPhone native apps are, in fact, just nicer looking copies of an existing mobile web offering, perhaps with an added bell of whistle, like location or camera, but these added extras don’t really make or break the app. If you have the time and resource to develop an attractive native app, then by all means do so. However, which Micro-ISV has spare time and resource to throw around? And, wouldn’t it be better to invest that time and energy into improving the desktop app or to increasing your precious marketing efforts to get more users in the first place? Things to think about indeed.
The general trend out there is for more and more web apps to offer some kind of mobile option. At the moment, if your product offers some kind of mobile support, then you might have an edge over your competition, but I would be realistic and say that this shouldn’t be your only edge as it is likely to be a marginal one. However, watch out for your competitors going mobile. You wouldn’t want to be the only one without a mobile option. You can also sign up for your competitor products to see how well their mobile offering works before undertaking your own mobilization efforts.
As with all software products, make sure that you have a means to monitor the success and usage of your mobile offering. All the usual Micro-ISV advice applies here, such as the benefits of co-opting active beta users willing to give you feedback. One tip here for cut-down products is to add a means of feedback into the mobile offering. I have seen users willing to give feedback via a mobile channel who wouldn’t bother to go onto the main site to give feedback.
And what about monetization of your mobile offering? Generally speaking, if mobile is essentially an enhancement to your product, then it’s difficult to charge money for the mobile option. However, mobile does offer the distinct advantage of a monetary relationship with the user via the operator or some aggregator, such as a premium texting gateway service. It is possible to get a share of money from services that exploit premium rate texting and, increasingly, premium rate video.
To gain money from the mobile app in the first place, then you need a means to charge the user and then release them the application. This isn’t any different to the usual distribution methods for software over the net, but there is the added possibility of distribution via one of the various mobile applications marketplaces. We have mentioned the iPhone app store, but there are others out there. Many operators have some kind of marketplace for mobile applications and you should check to see what’s available in your region.
In the mobile portal world, there are two kinds of distribution; what’s called off-deck and on-deck (or off-portal and on-portal). On-deck means that your application is available through the operators own mobile portal offering, which tend to experience high user traffic. However, this doesn’t necessarily mean high visibility for your app. Unless it’s a top-pick, it’s all too easy for apps to become buried away in some list that users hardly come by. Off deck means that your app can be downloaded by end users via some portal other than the the operator’s one. Off deck distribution is common for mobile games, with plenty of mobile games distribution sites out there.
Mobile is fun and its far easier today to gain mobile reach via the myriad devices, mobile browsers and easy-on-the-pocket data tariffs. Moblization is becoming just another tick-in-the-box for many software products. However, for Micro-ISVs, the benefits need to be considered carefully. Be self-critical with making sure that mobilization brings true added value to your users. Find ways to mobilize gently at first, testing the waters and getting feedback from users. Be opportunistic in terms of finding new distribution and marketing outlets for your product and riding the wave of interest in devices like the iPhone. Have realistic expectations. Mobilization is likely to be a means to bring more users to your basic offering rather than a monetization route in its own right, but be careful not to divert too much resource away from your core value in your non-mobile version.
Paul Golding, is a leading expert in the mobile applications world, author of the best-selling book “Next Generation Wireless Applications – creating mobile applications in a web 2.0 and mobile 2.0 world” (Wiley, 2008) and formerly Motorola’s Chief Applications Architect. He has taken numerous mobile products to market and is a consultant to many leading operators, vendors and start-ups. His blog can be found at blog.wirelesswanders.com.
By Paul Golding