tgeller writes “Drupal developer Ben Buckman attended the BostonPHP Framework Bake-Off with the hopes of pitting the CMS against CakePHP, Symfony, Zend, and CodeIgniter. He was told that he couldn’t because Drupal is ‘not a framework,’ a response he felt was ‘coder-purist snobbery (“it’s not a framework if you build any of it in a UI”).’ So he decided to unofficially compete in the back of the room by accepting the challenge of building a job-posting app in 30 minutes, while the official competitors did the same from the stage. He recorded the results, which are impressive. In the process he raised the question: What is a framework, anyway?”
The Android world’s been a-buzz this last week over a few new Android Market URLS, including http://market.android.com/music/ and http://market.android.com/movies/. In case you thought there was nothing to this tip, guess again: the third member of this trifecta (http://market.android.com/books/) has gone live. That’s right, visitors to the Android Market can pick up Glenn Beck’s mile-a-minute thrill ride The Overton Window for a mere $9. We hope that takes some of the sting out of the fact that a Google Music launch wasn’t part of this month’s Honeycomb event — although if we had to wager a guess, we’d say that the company will have Music and Movie offerings soon enough.
Google began rolling out Thursday a new search feature that makes finding recipes on the web a little easier.
Dubbed “Recipe View,” the feature lets users filter search results according to ingredients, cook time, calories and more. Users can search, for instance, for recipes containing brussels sprouts, devised by chef Ina Garten, that take less than an hour to make. Pictures, ingredients and one- to five-star user ratings are highlighted in the listed results, helping users quickly discover or bypass recipes.
To use Recipe View, simply select the “Recipes” link on the left-hand panel when searching for a recipe.
Google plans to enable the feature to all users in the U.S. and Japan by Thursday evening; it also plans to introduce the feature to additional countries in the future, a Google spokesperson said.
DropPhox (US$1.99) from DaVinciWare Inc. is a little gem that everyone using an iOS device with a camera (and Dropbox) should go out and buy. This app allows you to snap pictures or videos, and have them wirelessly transfer to your Dropbox account via either 3G or Wi-Fi. We love Dropbox around here and use it for just about everything.
The first thing you’ll do is link DropPhox to your Dropbox account. By default a folder will be created in Dropbox — named, not surprisingly DropPhox, but you can change it if you’d like. Once you take a picture, if there is a connection, the pictures or videos will transfer. If no connection exists, transfer will be put on hold and resume as soon as DropPhox detects one. That’s it. It works seamlessly, perfectly and every time.
There are a number of things you can set either in DropPhox, or in the Settings app to tailor things to your liking. The first one is the size of the image. I don’t have an iPhone 4, but on my 3GS, I can choose between, original, 1200×600, 960×1280, or 600×800. This is important, since an original resolution shot can be over 3 MB large, and sometimes you don’t need the higher resolution image in Dropbox. In the Settings app, there are also options to enable or disable saving to your camera roll, choose a date format (all the shots are named starting with the date, so this may come in handy) and a few other settings. In the DropPhox app, you can provide the needed Dropbox settings, select a saving directory and turn Geotagging on or off.
Aaron Maxwell is founder of mobile web design agency Mobile Web Up. You can find him on the agency’s mobile business blog, where he writes about mobile and social media.
Almost every business is gearing up their mobile strategy. No secret why: Mobile is really taking off. There are already more people on the planet who communicate with text messages than with e-mail and more people who own phones than have credit cards, according to the latest statistics.
The difficulty is that there are many facets of mobile technology. Apps, websites and SMS form the broad foundation. But mobile payments and advertising are rich topics on their own. Where do you focus first?
For many companies, the answer has been “an iPhone app” (notice I said iPhone app, not mobile app. More on that later). But people have also been looking into mobile-optimized websites. That has led to a kind of debate in some circles about which is more important. If you’re going to only do one, is it better to make a mobile app or a mobile website?
Apps have one clear advantage. In general, a well-made app can provide a far better user experience than even the best mobile websites are capable of right now. I don’t think this is controversial.
Really, though, what I often see missing from such discussions is cost. It’s often not that hard to make a web app that will work well on most smartphones (depending on the nature of the app — things like graphics-intensive games being an exception, etc.).
But making just a native iPhone app is usually harder than making an equivalent cross-platform web app. And if you want Android and BlackBerry users to be able to have a native app, too, you often have to build each platform from scratch.
Types of Apps
Let’s make an important distinction here. Apps can be divided into:
Those that are meant to directly generate income, and
Those that are built for purposes of marketing, branding, or customer service.
The first type is the topic of all those heartwarming stories about some enterprising developer creating an iPhone app in his spare time, from which he is making more than enough to quit his job coding TPS report generators at BoringBigCo. There are also real companies that do create and sell apps, quite successfully. The income comes from charging for the app directly, in-app purchases, and subscriptions, or less directly, through advertising (think Angry Birds on Android).
If you’re charging for your mobile product, a native app is the way to go. A mobile website can’t integrate with iTunes billing, which — in addition to providing a ready market of 125 million mobile users — makes payment a snap. Charging for access to your mobile website will require rolling your own payment solution… a tall order on mobile right now.
While interesting and exciting, this category of mobile app is not really what we’re talking about in this article. What’s relevant is when companies produce apps in the second category, for the purposes of marketing, branding or customer service. Good examples are the Starbucks or Target Stores apps.
These are normally free, since the whole point is to get them distributed as widely as possible. And that changes the discussion completely. If we make an app, how many prospects and customers will it reach? That puts a ceiling on the potential success of the app as a marketing channel.
The Reach Of Different Mobile Channels
From a pure “how many prospects can I reach” perspective, the best mobile marketing tool is text messaging. About 68% percent of American cell phone subscribers sent a text message in late 2010, according to comScore’s mobile market share report.
Of course, you can do things with apps and websites that you can’t do with SMS. So how many people can you reach with an app? And how many with a mobile website?
For mobile websites, it’s easy. The best indicator is how many people actually browse the web on their mobile phones. As of late 2010, it’s currently over 36% of all U.S. mobile phone subscribers. So, about one half as many people as you can reach with a text message.
There is more to the story for apps. I was at the San Francisco de Young museum a couple of weeks ago. They threw a little shindig to celebrate the release of their official mobile app.
The only hitch: You could only install it if you had an iPhone. Those of us with Androids and BlackBerrys couldn’t play. That reflects a current reality with apps. An iPhone app only works on, well, iPhones. Your app has to be made separately for each platform.
In North America, the most important smartphone platforms right now are iOS, Android, and BlackBerry. How many mobile users are on each? Here are the ratios in the U.S., as a percentage of all mobile phone users, for the last quarter of 2010:
iPhone: 6.75%
Android: 7.75%
BlackBerry: 8.53%
TOTAL: 23.0%
In other words, if you decide to only make an iPhone app, fewer than 7% of all mobile phone users will be able to use it. If the app’s primary purpose is marketing, you’ll need to decide whether this reach is big enough to be worth it.
And if you develop three different apps to cover these three most common platforms, you’re going to potentially triple your cost. All so you can reach only a fraction of the number of people you can get with a mobile website.
To make things worse, I’m ignoring Windows Phone 7. A year from now it may have a very significant market share, thanks to Microsoft’s joint venture with Nokia. Most mobile websites will work fine on the new Nokia/WP7 phones the day they are released. But creating and pushing out a Silverlight mobile app is no small task.
Apps Aren’t Free
The costs for this can add up. There’s no such thing as a “typical” app, so it’s hard to give a meaningful average cost. But as a general working figure, we can say it costs at least $30,000 to design, implement and deploy a brand-quality iPhone app. I haven’t found published studies for the equivalent costs for Android and BlackBerry, but since the device fragmentation is greater, it would makes sense that the costs are at least similar.
All the above means that, at the end of the day, creating a set of mobile native apps that reach, say, 80% of smartphone users is going to be far more expensive than creating a mobile web app that reaches 90% of smartphone users. I don’t even mean twice the cost; I mean more like five, maybe even ten times the cost.
In many situations, that’s acceptable. As noted, sometimes you want to do things that just aren’t possible with a mobile website, at least with good quality. Or maybe it is possible, but you know you can create something of better quality with a native app, so that the result is more engaging. For enterprise-scale organizations like consumer banks and nationwide retail stores, they have the capital, and the ROI justifies it. But if your budget for mobile is under $100,000, it may not be a good approach.
How does a mobile website compare in cost? I haven’t found any published study of the typical cost for mobile web design and development. But from my experience running a company that does just that, I can tell you that it’s almost always less than the $30,000 for an “average” iPhone app.
What’s the ROI?
Given all this, how many prospects will a venture reach per dollar? At a conservative estimate of 234 million U.S. adults with mobile phones, here’s the breakdown:
In other words, you can reach nearly five times as many people per dollar invested with a mobile website rather than a native mobile app. And that’s conservative, assuming it costs just the same to create the BlackBerry app as it does to create the iPhone app (it doesn’t), or that a mobile website will cost the same as an equivalent iPhone app (generally, not even close).
Does this mean you shouldn’t do an app? Of course not. There are many other factors involved. If an app user converts 10 times more frequently, for example, the difference is more than justified. But that’s a big hurdle to clear. And if you want to reach users across more than one mobile platform, you have to consider the extra capital investment as well.
Whether you go with a mobile website, a native mobile app, or both, you’ll probably benefit. The continued mobile explosion will make sure of that. Just take care that you get the most bang for your buck by doing what’s best for your business.
