Base Mobile Applications

There’s a decent amount of chatter about microcredit/microlending being used in developing regions, and plenty of respect paid to the need to get “the unbanked” represented in mobile payment systems. But what about filling out the rest of the desktop base services with mobile equivalents? Just the normal base productivity apps. What happens once these folks get up and running? Is there a need for a Quickbooks equivalent that’s entirely mobile? How about backups that don’t involve syncing back to a desktop you probably don’t have? If you needed to run everything you did on a daily basis from mobile devices only are all the necessary parts in place?

I’m a developer, so the answer to that question has always been no. Although us developers are pretty much “pure” online interaction – we don’t have a lot of the need for offline interaction that lots of other professions do – everyone just assumes that if you’re going to be a developer you’re going to have a computer system of some kind. What if that wasn’t the case however? What if the knowledge of local conditions or business models trumped the other concerns? What are the tools you could use to get the job done if you had a business opportunity and a mobile phone, and that’s it? These are the kinds of questions that have been dragging me out of bed lately.

Posted in Android, Community, MobilePayments, Software, Technology, ThisIsMobility | 3 Comments

SmartMeter Sensor Network

I was at the SVC Wireless conference this weekend, and caught the Internet of Things panel. A decent amount of the conversation revolved around revamping the power grid. Despite hearing about “concerns about the new SmartMeters here in California” on the news a number of times, it wasn’t till this weekend that I learned that the SmartMeters are a mesh sensor network. Last time I heard about these bits of technology it was very much research, and at the time folks were calling it smartdust. Nice to see it has worked its way out into practical applications, unfortunate to see the crackpots causing so many issues with the application.

It made me think a lot about the shifting mindshare (or maybe share of attention?) going on in mobile. Back in 2003 and 2004 stuff like ubiquitous computing, RFID, and sensor networks were part of common conversation for just about everyone “working in mobile”. In 2010 when you mention mobility iPhone and Android pop to mind immediately, and the discussion only infrequently makes it outside of handset technologies. The attention goes where the money flows, not abnormal. But I was somewhat surprised to realize how long its been since I’ve thought about some of these things. And in some cases surprised to see how far some of the technologies have come even though they’re progressing effectively under the radar.

Posted in Community, Technology, ThisIsMobility | 2 Comments

Mobile 2.0 Reflections

With another Mobile 2.0 conference just wrapped up I wanted to just highlight some of the topics and conversations:

  • Irv Henderson from Yahoo kicked off the topic with a presentation that included a sub-$100 phone that included a bunch of smartphone level capabilities (covered in detail by Dennis in his wrapup of business day). He was demoing the browser in particular, and how Yahoo is using the mobile web to reach all these devices that it would impossible to port to. Lots of other folks in conversations picked up the thread however. In particular I detected an edge of panic from handset and operating system providers whenever the name MediaTek was used
  • Lots of talk, as always, about addressing the developing world. But the talk always seems to be very high level pontificating. My attempts to nail down even just one or two solid bits of advice for folks interesting in addressing that market with a new offering mostly came up empty. One bit from Purnima Kochikar did register however. She noted that in India in particular folks do not want subscription/bundle services. They would rather pay more for a single-serving version and be able to pick and choose on their own. She used the example of a video service that that charges a small amount for individual clips, and is doing quite well with the model. Practical advice FTW!
  • From the developer day stuff I was blown away by how many folks are using PhoneGap. Most objections to using the mobile web can be answered for almost any platform with “well just wrap it in a PhoneGap project till that kind of thing gets fixed”. The Palm folks use it, Nokia uses it, the toolset folks use it. Fantastic to see.
  • For a while I’ve been saying that tying more offline purchases into mobile will bring the real state-change we’ve been looking for in mobile advertising. It looks like the way that’s starting to happen is via geo-local advertising. It doesn’t sound like the standards have followed here (no one I spoke to knew of MMA or IAB standardized methods for specifying the geo info associated with ad buys), but folks on the panels claimed that advertising spend on local services was up significantly so far this year. Foursquare is the main driver of conversation here, but apparently couponing and incentive offers in apps like Yelp, on yp.com, and through Navteq LocationPoint are starting to open up the door. Those local ads tend to be drivers for real world commerce… so this should be fantastic news.

Probably my biggest realization however was how much mobile has grown. I actually learned a lot at Mobile 2.0 developer day, cause I’m just not able to follow everything interesting happening in mobile. 3 or 4 years ago that wasn’t the case, it was pretty easy to play with all the new stuff and be aware of all the activity. I just can’t do it any more though, it seems like every time I turn around there’s a new tool or technique I’m not aware of. I was chatting with Bruce Jones from GetJar about it, he’s been around for quite a while too. I was actually wondering if I’m just getting too old and tired to be able to cover everything, and he suggested that there’s just more going on. So it could be that he was just trying to make me feel better…

I don’t think that’s the case. If I take a look at the lineup of mobile related events happening this month it’s staggering. When we started doing this it was pretty much us and CTIA. Now there’s MobileBeat, AppNation, Mobilize, D4M, MobiTechFest, Think Mobile, and more. I think that’s a pretty solid indicator that the growth is real.

Posted in Community, Technology, ThisIsMobility | 2 Comments

Android Numbers Game

As far as number of handsets out in the market go Android has been wonderfully successful. Most folks agree that all things being equal, the number of Android handsets is going to surpass the number of iPhones pretty soon. Generally that’s been taken as a sign that developers should start thinking about Android cause it’s going to be the next gold mine. I’ve started to question that a bit however.

I’m a huge Android fan. My main phone right now is a Nexus One. I would actually like to see Android grow into a viable competitor for the iPhone. But there’s this huge glaring dark spot with respect to the number of handsets in the market determining the viability of the platform. If number of handsets out in the market really was the determining factor in the viability of the platform then Nokia would have already won. So obviously, it’s got to be a more complex issue.

So if it’s not number of handsets out in the market what would be the signaling factor, what else do we need to pay attention to? As far as third party developers go, their main set of concerns revolves around their ability to make money off their applications – either through direct sales or by monetizing audience. Right now the iPhone does that far and away better than the Android Marketplace does. Why?

I think a lot of it boils down to consumer disposition. Completely outside of the technology itself, it’s more of a marketing or psychology problem. I’m just not familiar enough with the terminology here to know what to call it. But the iPhone is a consumer pull, and Android is a service provider push. Apple seeded desire for the iPhone with a brilliant marketing campaign, and for the most part folks who get an iPhone genuinely want an iPhone. They know what an iPhone is and they know what they can do with it.

On the other hand, lots of the folks who end up with Android devices didn’t necessarily make a decision to get an Android phone. Snag someone in an elevator some time who has an Android phone and ask them why they got it. Generally they’ll say something like “it’s less expensive than an iPhone” or “I didn’t want to get on AT&T” or “I’m not an Apple person”. It’s not that they went out to explicitly get an Android phone, they just went out to get a good phone that isn’t an iPhone. What got sold to them was an Android phone. There’s a whole other discussion about if carriers are driving Android sales harder cause they’re making more off each Android unit in the field than they are off iPhone.. but lets skip that one for right now.

Because the consumer motivation started out different, their behavior ends up being different. I’m not sure if it’s causality or correlation, but Apple has setup the App Store in a way that it seems to drive a ton more sales than the Marketplace does. I’m not saying that the Android technique isn’t valid. Just that an equal number of Android handsets in the market does not make it on par with iPhone as far as third party developers go.

Posted in Android, Community, Technology, ThisIsMobility | 9 Comments

The Right Tool For the Job

A few days ago Bryan Rieger posted some fantastic slides about rethinking the layout of site resources for content meant to go to mobile devices from Yiibu. There’s some great stuff in there related to applying progressive enhancement principles to the layout as a whole, and the follow-on has spilled over into the mobile web discussion group about how to deal with desktop browsers that don’t do well with media queries. Great technical discussion and happy to see it happening.

However, I’m struggling with a big disjoin between what’s possible and whats practical and productive. We’ve gone through the discussions plenty of times before regarding the economics of developing for lower end capability devices (users of those devices segment into different demographic buckets, finding ways to address them is more difficult, etc). So lets just assume that folks using lower capability devices make good users and they’re people you want to address as users.

I talk to a pretty decent set of web developers on a pretty regular basis. Some of them have started to get excited about developing for the mobile web. I hear them say things like they’re happy they don’t have to pick up a whole additional set of markup to make things work on mobile devices, that they’re happy lots of the base functionality is showing up directly in javascript API, and that the layout engines have gotten good enough that they can make pleasing web experiences. Generally I don’t hear too much from the web developers about being able to hit wide swaths of devices with the same set of markup and styles. And I can’t recall any of them saying they’re anxious to supplant the programming models they’ve come to develop with different architecture for web design. Actually, I hear things like “it works on the iPhone, that’s what I have anyway, I don’t care about Android” more often than I’ve heard people discuss how to make things work consistently on both platforms.

Whenever the discussion starts to revolve around hitting multiple handsets, it’s always driven by people already in mobile. It was my impression that the next generation of mobile web technologies was supposed to cater to the existing set of web developers and make mobile an attractive option for them. I’m not seeing that happen however.

So my question is for what group of folks is this going to be the right tool? I’m certainly not a web developer, but I understand the stuff that goes on there. But you don’t even really need to be familiar with the technology, all you have to do is take a look at Twitter on any given day at the discussion going on with web developers. Quite a bit of it revolves around bitching about “cross-platform” issues, which normally means getting the stuff to work on different browsers even when we’re dealing with full desktop layout. Now we’re talking about supporting different device resolutions and orientations all using different browsers (or at least different versions)? I can’t see the web devs I know jumping out of their seats to volunteer for that.

The technique that I see most folks using is segmenting their traffic and swapping things out on the web server. They design for desktop, high capability mobile, and low capability mobile. They detect what device they’re serving to normally based on the user-agent, and then serve up the correct version directly. Both techniques have issues, granted. Lots of issues. It seems like the “new new” of progressive enhancement laid out in the slides would work best when you’ve got:

  • Folks working on the implementation who are at the deep end of HTML/JS/CSS
  • An environment where the pages need to be static and server side switching isn’t available
  • There’s a minimal amount of application logic.. trying to interleave dynamic content updates and event responses with the complexity of adaption seems problematic

Or am I missing the boat here? Is there a way to apply this stuff that significantly lowers the bar for implementers? Or plasters over a bunch of these complexities? Or merges together the different models and techniques? Cause it’s hard enough to convince the web folks I know to even play around with iPhone, we’re just starting to make some inroads there. If I laid something like this in front of them they would probably kick me. So, please, educate me. How do we put things together so that doing web development this way is compelling to someone who isn’t already a mobile devotee?

UPDATES:

PPK is rising to the challenge and trying to lay out how things should be working. Here are his responses:

Daniel Hunt has also followed up, with a different take than PPK, saying that device detection is an essential element of being able to deliver a great mobile web experience.

Posted in Browser, Community, Software, ThisIsMobility | 10 Comments

“App” Doesn’t Have to Mean “Native”

With AppNation wrapping up earlier this week and Mobile 2.0 happening next week I’ve been thinking a lot more about industry level shifts in mobile. Normally I’m heads down in some bit of server code lately, so it is relatively infrequently that I pop up and genuinely take a look around. One thing I was surprised to see is that whenever I talk about mobile apps it’s assumed that that discussion applies only to natively coded platform-specific applications. Definitely not the case.

In my opinion there are two major factors from the mobile web side that are pulling “web apps” into the broader discussion of applications. The first is offline web applications, which provides a way to specify a set of files that should be downloaded and cached locally so that the browser can continue to serve up the application even if the underlying system is offline. Besides the obvious benefit of being able to operate when the system is disconnected this also commonly means that the web application is given some kind of “desktop presence”. On iPhone I’m seeing more apps that lead the user through the process when they first connect to the app that results in an offline app with an icon in the launcher. This was one of the issues that most expected was hindering the mobile web, getting users to return to your app even if they liked it. I haven’t seen the same thing in practice as often on Android devices, but the common frameworks seem to be working on abstracting out this pattern across device types. I expect to see it a lot more. Having a manifest file that lists all the necessary resources also explicitly draws boundaries around your application. Sure, it’s still a web app built on HTML/CSS/JS, but it’s also in a very real sense also “shipped software”.

The other big factor is the single page web application pattern that seems to be gaining popularity. The entry point into the application is a static chunk of resources which dynamically loads the info necessary to present the app. It’s a shift from the content of the pages being the primary organizing principle the the functionality of the app being first and foremost. Organizing in this fashion actually complements the offline functionality quite well. However it presents a few issues too. It requires a few acrobatics to make sure the application functions in the absence of some of the functionality, and to ensure that users can bookmark pages sensibly and search engines have some kind of content to grab onto. I’m also not exactly sure yet how something like rearranging content around a simple layout and progressively enhancing would lie together with the single page app ideas. Seems like they would complement well, but we’re raising the bar pretty high at this point for web devs.

No matter how you slice it though, it’s pretty obvious to me at least that the conversation around applications isn’t just restricted to native dev. It isn’t even restricted to mobile. The granularity and structure of the resources being served up by all the web servers out there is starting to shift. Folks responsible for finding relevant info from the mass of data have started to pay attention to “the appiffication of the web” both on the desktop and mobile sides. I think right now we have a grab bag of techniques and some relatively new technologies that allow some of the bleeding edge folks to put together some really compelling apps on the mobile web. But I have no doubt that in short time all this stuff will be wrapped up and properly abstracted so that writing functional, fast, delightful web applications for mobile devices will be within the reach of most developers. And for the most part we’ll forget that we even passed through another era of native apps on the way to the mobile web.

Posted in Browser, Community, Open Source, Software, Technology, ThisIsMobility | 8 Comments

Why are Monetization and Distribution Lumped Together?

Frequently the two issues get tossed into the same basket when talking about mobile applications in particular. The most obvious reason for grouping the two together is that the main driver of both for most businesses is the app store. Getting top placement in the charts on the app store is seen as the holy grail of distribution, driving much larger numbers for most folks than any other technique. Plus the main source of income for most developers is directly selling their app to users through iTunes.

Even with that simple arrangement there is a degree of complexity to take into account though, mostly in the form of pricing. A high priced item is generally a higher margin item for the developer, but will also normally shift few units. Sometimes lowering the price so that you can get additional purchases will give you the extra lift you need to get into the charts, and the volume you sell will more than make up for the lower margins. It’s a very error prone process, because there’s so little hard data about individual applications available to the public. And even when you do have hard data it’s pretty hard to replicate previous successes because the marketplace is evolving rapidly.

Then there are a few hacks you can use to segment the two functions. The most common is having a free or low cost ‘lite’ version of the app and charging for enhanced functionality either via in-app purchases or having another version of the app with a different price. This allows the lower cost version to hopefully make it up into the charts for you and serve as a marketing function, while being able to keep the price of the full version at a point where the margins are a bit thicker without losing out completely on the exposure the app store itself can get you. The other option is to offer the main app for free and use some kind of in-app purchasing for segments of functionality or content, the so called freemium business model.

Then there’s advertising and affiliate programs. The success of advertising and affiliate programs is majorly a function of how large your audience is. The number of users your app has. And (just as important!) how often they use your app. It’s not very useful to try to advertise with a generic network in an app that’s been downloaded 3 million times, but only has 30 thousand active users on any given day. However the success of an advertising or affiliate program is also a function of how strongly segmented your audience is. For instance if you have 1 million users from all age groups and all walks of life, you might not have the kind of audience you would be able to find eager advertisers for. However, if you have 500 thousand users, all of who live in the San Francisco Bay Area, have indicated in some way that they’re at an auditorium or concert venue in the last week, and tend to be in the 18 to 25 age group – you could probably find someone looking to reach those people.

This is where the fundamental tension comes from. If you setup your app to do well getting directly sold through the app store (broadly appealing, low cost) you normally have to tilt things in the direction of that being your major monetization route. If you raise the price to where you can make decent money off the initial sale you’re normally also cutting the audience side down and limiting the scope of the advertising and affiliate programs you can run. Same thing with more directly targeting your app. If you make the app more specific and compelling to a smaller group of users, you can raise the price. But if you raise the price you usually also cut down volume.

This isn’t to say that you can’t come up with a targeted app that you can sell at a decent price, but also yields a good audience for advertising and affiliate programs. After all that’s what magazines do. They’ve managed to charge for buying the issue off the newsstand, but also take advertising money from companies who want a presence in that issue. However, I frequently hear the options expressed as either/or by app developers. They feel if they charge for the app they shouldn’t be running advertising. I understand where that sentiment comes from, but it’s not the way most other areas of business operate. I wish my cable provider didn’t run advertising in exchange for my paying for the service, but unfortunately that’s not the case.

Our first panel discussion at Mobile 2.0 developer day is going to explore a bunch of these issues, in addition to some talk about alternative distribution models I’m sure. Peter from Rovio is going to weigh in on how Angry Birds has managed to hold the #1 paid app in the app store for just about every region. They’ve sold more than 6.5 million of the paid application to date. Chris Dury from GetJar is also going to be present, he had some fantastic commentary at a recent Mobile Monday when he summarized the options available to developers as get featured, get targeted, or get viral. Sean from Flurry is going to be weighing in not just on the AppCircle system they have setup for promotion and monetization in-app, but also bring some numbers to the conversation from the huge base of info Flurry collects on the analytics side. Jahanzeb from iTeleport is going to represent the targeted side of the house, discussing how their app makes more than $1k a day without ever appearing in any charts at all. And finally Raj Singh is there to moderate, he’s worked with big companies, startups, and frequently his own efforts to find novel distribution and monetization models for consumer mobile apps and services.

If you want to join us at Mobile 2.0 use the promo code ‘friends’ for a 20% discount off the normal ticket price. Hope to see you there!

Posted in AdMob, Community, iPhone, Mobile Monday, Software, Technology, ThisIsMobility | 1 Comment

Mobile 2.0 2010 Silicon Valley

Mobile 2.0 2010 Silicon Valley is next week. We have the event divided up into two days again this year, with the developer day on Sept 20th at Microsoft in Mountain View and the business day on Sept 21st in San Francisco. You can use the code “friends” when you sign up for 20% off the normal registration price.

One of the major themes for 2010 that became apparent as we were putting together the lineup for developer day was the increasing momentum behind the mobile web. A few months ago it was looking like a pretty strong trend, and the last few months have seen even more activity than I expected. The folks at Sencha pulled down a bunch of funding, a formal release of jQuery mobile was posted, and we’ve seen folks like OpenAppMkt take the first steps toward paid distribution of mobile web applications. So I’m happy to say that with the benefit of hindsight, including a lot of mobile web focused content seems even more relevant than it did a few months ago. W00t!

There are probably a few major factors driving the increased attention that the mobile web is getting. There are two that I hear probably most frequently, with about a 50-50 split between them depending who I happen to be talking to. The first is that folks really want to get back onto a release cycle that looks like the web release cycles they’re accustomed to and not the shipped software cycles they’re bound to when working through the app store. Even if they can’t necessarily get everything done exactly the way they want to on the web, having to make a few compromises in terms of functionality is worth it to be able to update your application at will. This seems to be particularly true with folks who are already accustomed to web development, and just assume that iPhone dev will work somewhat the same. What I’ve been surprised by are the number of folks who jump into native mobile dev and only start to realize the problems after they have apps out. Eventually they say something like “Hey, how am I supposed to do A/B testing in an iPhone app?” and the problems start to snowball from there. I’m seeing an increasing number of folks in this category.

The second major driver is the increasing attention folks are paying to Android as a platform. Although tales like Advanced Task Manager has to tell of great revenue number on Android are few and far between, the increasing number of handsets out in market and the evolution of the platform are drawing more and more attention. It’s been true for a while that free apps from major plays will have an Android version to ensure the app provider gets decent coverage of their user base. But recently folks that are shifting significant numbers on iPhone are starting to look at Android as an additional paid distribution channel. Angry Birds testing out the waters of Android with a recent beta release is an excellent example of something we’ll probably see a lot more of. On the paid distribution side a native port is pretty much a necessity. But for folks just coming to market now, especially those looking to monetize through in-app sales or advertising, the mobile web is looking increasingly tempting as a way to go cross platform without having to plan for porting.

If that’s the kind of conversation you’re looking to have, check out the lineup we have for Developer Day this year. If you factor in the “friends” discount it comes out to $88 for the day. I think we’ve served up a fantastic lineup for the cost.

There’s also a Best Practices for Mobile Design event we have going on the evening after the Developer Day. It’s just down the road at the Computer History Museum in Mountain View and the schedule starts after the developer day program ends. So if you’re planning to come for developer day, please also join us at Mobile Monday by RSVPing at Eventbrite.

Posted in Android, Browser, Community, iPhone, Software, Technology, ThisIsMobility | Leave a comment

Evaluating App Store Opportunities

We had an awesome discussion about App Stores at Mobile Monday SV last night:

Mobile Monday Silicon Valley - August

Thanks to everyone who came out to participate and made it a fantastic night, it was a great set of conversations! Much of the conversation focused around distribution and monetization, those are the hot button items generally speaking. There seemed to be a decent amount of doubt from some of the audience however that one could put together a profitable business in mobile. Chris Dury from GetJar had a fantastic summary of the options a developer has: get featured, get targeted, get viral.

The featured one is usually the first one everyone talks about. How do you make it into that coveted top 25 list on the AppStore? Have a great app, make something with wide appeal, time your marketing and PR pushes for maximum impact, price appropriately for large download volumes. Lots of folks get ruffled feathers about this setup by the way. It’s called a hit-driven marketplace, borrowing a term that seems to have been reserved mostly for the gaming industry previously. Which means if you’re at the top of the pile you make a whole ton of money, but if you’re at the bottom of the pile you don’t make crap. And with more and more titles in mobile app stores, and big corporations with deep pockets participating, people argue that there’s no way for a small independent developer to make money in the app store any more. Bullshit – but still, it’s what people say. It just means there’s competition now, and that you can’t release junk and expect to make wads of cash. Most of us don’t expect that though, so it’s just a point to consider and not a market killer.

The second method is to figure out a segment of users you’re going to be generally appealing to, users who are willing to pay more than the general population for what you have, and spend some money to reach those users in a targeted fashion. For a fantastic writeup of the principles in practice, checkout the blog posting from the iTeleport folks about how they’re making money despite never making it up into the charts. They’re never in the top 1000 apps actually in any region. But they manage to make north of $1000 a day through AppStore sales. Really this is about basic business principles. I’m surprised how often I speak to folks looking at doing a mobile project who don’t have the floor nailed down here. The major questions you need to answer here are: how many users are there out there who match your segment, how much does it cost to reach a user, and how much do you make from each user. If there are enough users, and you make more off of them than it costs to get them, you’ve got a business. There’s nothing magic about this on mobile though. This would be the same if you were running a boutique clothing store, selling decorative masks on the street, creating a new line of dietary supplements, running a restaurant, etc. It’s just business. And good business is good business no matter where you do it, just as crappy business planning is crap no matter where you do it. If you decide to release a poorly implemented application with no differentiating features for $5 on a mobile app store and fail to make money, that’s not the app stores fault. If I decided to try to sell twisted paperclips for $10 a unit in Union Square and didn’t make money would it be the fault of Union Square as a business venue? No. It’s because you’ve built a business that isn’t good enough to compete. Own up, it’s a necessary part of progress.

The third method is to go viral, which really means not relying on the app store itself to get you in front of new potential users, but to rely on your current users “getting you new users”. I don’t want to get into this whole area of how viral transmission works, explicit sharing vs. data exhaust based linking. While it’s a great topic, it’s just too huge and complex. But if you want an example the most relevant today is probably FourSquare. I will point out however that viral can actually lie in perfectly well with getting featured or being targeted. Running a good viral campaign could get you the download velocity to get up into the charts and propel you even higher. And a well structured set of viral features could lead to you getting in front of additional targeted users if you plan things in a way so that your viral hooks tilt usage in the direction of a behavior you’re trying to support. Horrible simplification, I know, But that’s all I’m going to say.

So where does that leave us? How do you evaluate the potential of developing a mobile application as a business? It depends which of those vectors of transmission you want to appeal to. If you want to shoot for getting featured you really need to plan what you’re doing more like a physical goods business than in internet business. Way back in the dark ages of computers, before most of you were born probably, a major part of what software vendors used to have to worry about was distribution. There were physical boxes with install media in them sitting on shelves in a computer store. The concerns of software providers included things like shelf placement and how many stores they could get placed in. It’s still the way the console games industry works. And really, its the way a lot of the application stores for mobile work currently. It’s not that they’re physically limited the way that a store is, but by deciding to lay out their online store so that there are a limited number of slots they’re effectively taken digital distribution and forced it back in to the physical square-footage model of software distribution. Along with all the benefits and detriments that go with it.

If you don’t want to just spin the wheel on getting featured you’re going to have to do some additional planning however. We’re at the very beginning of a pretty major shift in the way that services are delivered. A few years ago it was a very small minority of folks who were thinking about how ‘mobile’ fit into their overall service plan. Now it’s pretty much taken as a given. Simply put, the model hasn’t been able to absorb the interest. Some of us are working on trying to figure out how to bridge that gap. How do you wring the inefficiencies out of the app world and allow for an environment that can see the kind of proliferation of services we saw on the general internet? We’re not there yet. So it takes some additional planning to avoid getting lost in the noise of the marketplace. But the potential is very real. Just take a look at the usage and adoption numbers. If that’s not a market worth going after I’m not sure what is.

Posted in Community, Mobile Monday, ThisIsMobility | 2 Comments

The Web is an App (Via Diego)

Diego is updating his blog again! Awesome! Check out his “the web is an app” post for a laydown of how generalized web development is shifting. Things were already tilting in the direction of “websites” being basically a static javascript loaded that pulled in resources and data as necessary. Mobile devices have really thrown a few cans of gas on the fire however. Before it was just annoying when logic crept into display code. Now with multiple distinct front-end views it’s gone from annoying to painful.

The role of browser Javascript framework on the mobile end seems to be an area of hot contention right now. With behaviors optimized for touch devices being the headline item in most of the conversations I’m seeing. The Uxebu blog and Wolfram Kriesing’s twitter feed are good places to look if you’re interested in following how it evolves. One of the most significant recent changes is the rollup of the ExtJS, JQTouch, and Raphael projects into a new company and product called Sencha. They seem to be ahead of the curve in pulling everything together to build the mobile specific web interface on top of REST services the way that Diego is talking about. And their recent large investment from Sequoia would seem to indicate that they’re in good shape to extend that lead. Check out their online KitchenSink demo to see some of the interaction styles they support. Still lots of work to be done, but I’m hearing more and more developers saying they’re at least starting to evaluate toolkits like these for doing their mobile web UI.

Posted in Browser, Software, Technology, ThisIsMobility | 1 Comment