Today is the day. Mopocalypse has been the subject of tech world chatter for the past few months, and even PSA-type articles in mainstream media like USA Today: “Make sure your mobile site is ready.”

For those unfamiliar, Google in February uncharacteristically announced an algorithm update that will de-rank sites in mobile search that aren’t optimized. Mobile-optimized means no horizontal scrolling, zooming or unplayable content (i.e. flash). It won’t apply to tablets, video and local search for now.

Google has taken steps in this direction with incentives to clean up mobile websites or use responsive design. So this isn’t the first time site-friendliness is a ranking factor, but it’s a bigger tough-love moment where Google stresses consequences for bad behavior. It used the carrot; now it’s time for the stick.

But the question that reveals its larger mission is ‘why?’ Google is currently fighting a battle with the app world, and is behind if you consider that that 80 percent of mobile minutes are spent in-app, versus browser. The browser is where Google is the front door; not so much in apps.

The biggest reason apps are winning this battle is that they are often slicker and more functional than the relatively wonky mobile web. So making the mobile web less wonky — to put it bluntly — is Google’s biggest driver for today’s algorithm shift. A more user-friendly environment will boost traffic.

Meanwhile, to live in this app-centric world, Google also provides tools — both paid and organic — for developers to “deep link” to apps from search results. That way Google can become that front door to the app world, or a sort of app search engine to boost utility and revenue (app download ads).

Google Now is another play. It’s not only app based, but in-tune with the developing mobile use case of passive discovery as opposed to active search. So in some ways, Google is trying to beat the app world and in other ways it is trying to join it. This is to increase winning probability by placing several bets.

Bottom line: as mobile takes over, protecting Google’s place at the front door to all content is critical. Google NOW and Mopocalypse are central to that, though in very different ways. We’ll see many more efforts as there’s too much on the line ($60 billion in search revenue) for Google not to keep innovating.

The post Mopocalypse and the Eternal Battle Between Apps and Mobile Web appeared first on BIA/Kelsey - Local Media Watch.

While Apple iOS and Google Android have attracted hundreds of thousands of apps, BlackBerry remains stuck at some single-digit percentage of that number.

Is it that BlackBerry users don’t have the same appetite for apps that other smartphone users have? That would seem highly unlikely. It seems much more plausible that BlackBerry users have not been habituated to apps because there are so few of them, and frankly many BlackBerry apps aren’t that great.

The primary reason is that software developers shy away from building native BlackBerry apps. The platform is simply much more difficult to develop for than Apple iOS and Android. Some real examples:

1. Multiple Versions/Devices: It’s hard to make one BlackBerry app that will work well for all BlackBerry devices — there’s little standardization among RIMM devices. The “smartphone” BlackBerrys are touchscreen, whereas the other ones use a scroll-ball to move a cursor and make selections. There’s not even a standardization of screen sizes, which makes layout difficult and time consuming. To understand the issue in about one second, take look at the BlackBerry Operating System version chart on Wikipedia.

2. Testing: You can test your code on a simulator in the computer — but each simulator download is 150 MB (!) per device — multiply that times the devices on the above OS chart.

3. Internet Connectivity: Getting a connection to the Internet from your app is not at all straightforward. BlackBerry is designed for security, which means that all of your Internet could be running through a central proxy somewhere. This becomes problematic for development as the app code must probe and prod in order to figure out the best means of connecting to the Internet to fetch data from any sort of Internet-hosted datastore.

4. Debugging: In iOS, the development cycle is:
– change code
– click button
– watch the app load on the device and verify your code change

Now here’s the comparative debugging process for BlackBerry:

Change code, click button, watch your app get sliced in to 64kb pieces, a window prompts for your encryption password, each 64kb is signed by TWO signing servers (meaning that you need to wait for about 40 requests/responses for even a meagerly-sized app — making a build at the end of the day? forget it — the signing servers are too busy to handle all those requests; watch your e-mail box as RIMM e-mails you for every single piece that was signed (hundreds of e-mails); wait for the device to completely reboot; wait for the debugger to attach; then dig through the menus to find the “Downloads” icon to actually launch the app; then, as standard operating procedure, the debugger throws two or three error windows for which you are recommended to “ignore” per the RIM documentation; then you may check your code changes.

Bottom line: Development for BlackBerry is complex for UI, complicated for developers, resource intensive for computers, and time-consuming to test versus the Apple and Android environments.

Not surprisingly, BlackBerry has begun taking the position that native apps are a fad (see the article RIMM co-CEO interview with Barron’s this week), much like the AOL proprietary service was.

RIM’s position is that Web-based apps will dominate in the future. But only time will tell if it is right. At least for now, consumers continue to embrace the use of proprietary apps.

_____

Tobias Dengel is CEO of WillowTree Apps Inc., a mobile applications developer. He is also BIA/Kelsey’s new technical editor and will be posting regularly on mobile-related topics. The views he expresses are his own and do not necessarily reflect those of BIA/Kelsey.

The post BlackBerry Bets Against Native Apps (Again) appeared first on BIA/Kelsey - Local Media Watch.

Small businesses seeking to pick, choose and install Web applications for their Facebook Pages and Places can now easily do so with Appbistro, a new site that provides app makers an iTunes Store-like model (right down to the 70/30 revenue split).

The site, which soft launched at the end of May, now has 100 apps, with 43 more coming on in the next couple of weeks. It is already attracting about 70,000 users a month. A key advantage is that it provides more discoverability, especially for niche Web sites.

To be approved, each of the apps is tested for a few days. The site puts each site through heavy-duty testing before giving an app the green light of inclusion.

In addition to offering apps for download, the site also includes reviews and ratings. A typical app might be a menu app for a restaurant, or a billing app for an auto mechanic. Fees for posted apps currently range from free to $375 per month for separate apps that manage sweepstakes and virtual gifts. Some sites are available for free on a trial basis. In the near future, Appbistro is set to also begin listing featured apps on a vertical-by-vertical basis.

Appbistro is angel-funded and has eight employees, with three more coming on board in the near future. Its founders are CEO Ryan Merket, who has built 30 Facebook apps himself, and CTO Nalin Mittal, who had previously worked on the Zappos site.

The post Appbistro Simplifies App Finding (and Buying) for Facebook Pages appeared first on BIA/Kelsey - Local Media Watch.