Software Everywhere — David Beers on Mobile Computing

Mike Mace has written a piece titled Mobile Applications, RIP that seems far wide of the mark to me. He says that user-installed "native" mobile applications (as distinguished from web applications) have been so crushed by platform fragmentation and restrictive carrier certification requirements that the only remaining platform with a viable business model for mobile is the web.

Must be a Silicon Valley thing, because that's sure not been my experience. Nor it seems has it been Barbara Ballard's over at Little Springs Design, which has its foot in both the Java app and web app markets. She wrote recently:

This quarter is not particularly different from other quarters: we get far more work designing applications than designing web sites.

She goes on to explain why browser applications still aren't cutting it for her customers:

• Because they need to store some of their application logic and/or data locally
• Because the app or data needs to be available without the network
• Because the application would be dreadfully slow as a web app
• Because they are creating a push messaging client that needs more rich interaction than simple SMS (and better interoperability than MMS)

I don't think Barbara or I disagree with Mike about the challenges of fragmentation and certification, but I see things finally starting to get exciting for mobile developers, not dying out. Seems to me that all the really great new opportunities in mobile software involve applications that need access to the native hardware:

• LBS is finally taking off. (This is where I work these days and I get calls and emails asking for GPS apps all the time.)
• Mobile payments look poised to break out of Asia and into North America
• Companies are rushing to use QR codes to build the "Internet of Things", for which your mobile will be the mouse you "click" to gain access.
• Three words that make the above two items even more interesting: near-field radios.
• Multimodal user interfaces are finally looking ready for prime-time, so people can mix voice and button-clicks to create, search, and interact with their personal data and data in the cloud
• Best of all, mass market mobile phone users are starting to "get" the idea that their mobiles really can run applications and they're installing them to stay connected with their favorite social networks

Fragmentation is certainly not a reason for developers to retreat to the browser. The mobile web is incredibly fragmented, whereas Java ME fragmentation has been significantly reduced. And Java is looking like the new lingua franca of smartphones, too: RIM, Danger, Motorola, Google, and (rumor has it) Palm have all opted to make advanced (i.e. beyond MIDP) Java runtimes their primary smartphone application frameworks. A well-written Java ME application aimed at mass market feature phones is pretty easy to port to more advanced Java environments. The definition of "well-written Java ME application" will be a developer topic that I address very soon.

The carrier barrier does indeed make things tough—especially for "Long Tail" applications that address small niches. But we shouldn't forget that the carriers control the browser just as much as they do any other free-standing app. We know they are more than willing to control what parts of the web you can access without paying them a "toll." The only thing that's making web applications freer from carrier control right now for users who do pay that toll is that these apps aren't (yet) threatening any revenue streams or generating revenue from which the carriers can extract their pound of flesh.

Fortunately, as I watch the carriers struggle for ways to reduce subscriber churn and see widening cracks in the walls around their gardens, I'm more confident than ever that they will not be able to keep the forces arrayed against them out. That topic will have to wait for future posts. Suffice it to say for now that from where I stand there seems to be more good work for mobile developers today than ever. And I'm not talking about mobile web developers.

Just a quickie in between sessions at JavaOne.

I sat in on a very interesting session about OSGi (JSR 232) on mobile devices this morning and heard a lot of enthusiasm for this technology being expressed by Sprint. That's good news to me and you can read this to understand why I think it heralds a better day for mobile developers (if it actually gets good adoption). But what I found even more encouraging is the news that Sprint plans to release three to four new wireless "PDAs" during Q4 2007. It's not clear what that means (in some circles a BlackBerry is considered a "PDA") but since these were distinguished from "handsets" I think it's safe to say we're talking about devices that are focused on wireless data, not making voice calls.

This is such a good sign: good for developers and good for users. You see, part of the problem with the slow adoption of mobile data is that we're trying to get people to use it on mobile phones. The carriers have such a hard time opening up their handsets to applications because the expectation among users is that a phone has 99.999% uptime. Think about it: if you demanded that your desktop PC work as well as your landline telephone, you would have ditched the thing years ago and would probably still be buying postage stamps and reading newspapers. Consequently, the carriers are mortified that even one poorly written or malicious application could cost them customers for whom they have made considerable up-front investments with device subsidies. The result is that they often close developers off from doing anything interesting with the handset, or at least erect costly, time-consuming hurdles that few developers can afford to leap. The frustration level among the Java ME developers at JavaOne is approaching fury when they talk with the carrier reps in the sessions here because of the perceived hypocricy of these companies who say that applications constitute the value-add that keeps them from becoming "dumb pipes" yet seemingly block developers from getting apps to market at every opportunity. And the mood among those carrier reps is not any better, let me tell you. Being assigned to go to the world's largest developer conference probably feels like being fed to the lions for them.

So where am I going with this? Well, what makes data-centric devices so helpful is that they are not phones, so the huge user expectation that they will work like a public utility is off the table. This allows the carriers to (hopefully) losen their grip a bit and let the developer community innovate. Sprint is making a big gamble on this with a new, very open approach to devices and software that can run on their WiMax network. You'll be able to go buy a device from Best Buy and use it on Sprint's network before you even leave the building. These devices will not be subsidized, but you won't have to have a contract with Sprint to use them either. That gives Sprint the opportunity to think of other ways to keep people on the network, like encouraging a software ecosystem to flourish. If they deliver on this as they are talking about doing, I think the mood among mobile developers at next year's JavaOne could be a lot more positive. And as a user I'm really looking forward to seeing those WiMax-enabled Internet tablets!

First, the bad news: one of the most damning recitations of the shoddy treatment of developers by the wireless operators I've ever read. When will these companies learn to stop eating their young?

The good news? Open platforms are hot and hardware vendors are taking chances on significant value being driven through them even if they don't have cellular radios. Nokia's Internet Tablet was one of the first high-profile tests. Now Intel's Mobile Internet Device (MID), powered by a new super low-cost, low-power chip, is looking poised to make an even bigger splash by doing to the UMPC what Palm did to the Newton a decade ago.

The Open Source community is ready for them. The Gnome Foundation (whose platform technology is taking mobile Linux by storm) announced last month a Mobile and Embedded Initiative with great fanfare. And yesterday Ubuntu announced a mobile edition of its popular desktop Linux distro. Ubuntu Mobile Edition is planned for an October release and seems to be targeting hardware like Intel's new lower-cost MID devices. Here's Matt Zimmerman, CEO of Canonical, which maintains Ubuntu:

It is clear that new types of device—small, handheld, graphical tablets which are Internet-enabled—are going to change the way we communicate and collaborate.

As the progress of mobile technology starts to look increasingly like an end run around the wireless operators, eventually one will break rank and embrace content and software developers with open platforms. In the US, Sprint has started making noises that they want to do this for their WiMax network, which they say will be open for "any device, any application, without any contract required." Something tells me they may very well keep their word.

Mention the growth of mobile data (or lack thereof) and most of us think wireless data: "what are the killer apps for 3G or 4G networks?" Let's face it. Taken as a whole, high-speed wireless networks are still an answer searching for a question that most consumers don't have yet. But there is another kind of "mobile data" that strikes closer to the question of user experience and solving real problems. That is the data that is stored locally on the mobile device. While everyone is focused on what will drive wireless data usage, mobile OS vendors like Microsoft, Symbian and ACCESS have made some interesting changes in how your data may be stored on your mobile and what you will be able to do with it: each is baking a relational database engine right into the next versions of their operating systems.

That may sound like information that only a software engineer would be interested in, but I'd like to outline what I think it could mean to users. There's the potential for this trend to produce meaningful improvements in the mobile user experience, and maybe even open up new markets for smartphones by addressing pain points of real consumers.

It's my data, let me use it how I please

That sums up the familiar backlash of the user against DRM of downloaded media. But many mobile platforms encourage or even force developers to treat your personal data as if it was protected under DRM, too. Would you like to search for a text message you received last week and then save it as a memo or attach it to an email? Or share a link in your bookmarks with a friend? These simple things are difficult for developers to implement because text messages, memos, bookmarks and buddy lists are each stored in binary formats that only the application that created them knows. Even if the developer knows the format, that data is for some platforms totally inaccessible outside the application that created it, Java MIDP being the most notable example.

Just as open standards for data like XML and RSS are turning the Web into a platform characterized by interoperability, extensibility and sharing, standards like SQL can bring these characteristics to mobile platforms. Data stores like contact lists, messages, call logs, task lists, and voice memos can be queried, and this data mixed and matched by applications to create a more complete and flexible user experience.

One important kind of data that users generate constantly is rarely captured despite the fact that it is tremendously useful for personalizing and simplifying the user experience: data about usage itself. Information concerning how often certain pieces of information are accessed by the user or how they relate in actual usage to other bits of information should factor into how software responds to input. For example, if I've sent a lot of text messages to Linda this week it would be nice if my phone predicted that I was probably sending her another one when I entered just the letter "L" as the recipient and offered to autocomplete this information. (Following the "L" with an "a" would correct the wrong guess and offer a revised one: "Larry" perhaps.) This requires fast search capabilities that are hard to implement with current mobile data storage techniques. Relational database engines like MS SQL Server CE and SQLite use indexes, internal data structures and algorithms that make such on-the-fly searches instantaneous for users and easier for developers. Without spending a lot of time tracing out the implications I'd just like to assert that thoughtful tracking of device usage can make all kinds of operations faster and easier for the end user and become an important factor in improving the mobile UI.

Sometimes data is the (killer) application

Two years ago I had the good fortune to see Michael Mace give a great presentation on the segmentation of the mobile user market, of which this article is a digest with some helpful new diagrams and insights. Michael has done more than anyone else I know to identify a large, but as yet relatively untapped segment of the mobile device market that he refers to as "Information Users," as distinguished from "Communication Users" and "Entertainment Users." At this conference he presented many striking video clips of consumers talking about how they use their mobile devices, and it was easy to pick the Information Users out from the rest. Where others talked about how their mobile devices helped them keep in touch or entertained them with music and games, these people echoed things like "it's my second brain," "it watches my back," or "I keep my whole life in there." These users carry a smartphone or PDA because they need a place to off-load their brain and a reliable way to retrieve that information wherever they are at a moment's notice.

To some extent this segment of the market really needs a new device that hasn't yet been produced. But for a lot of us, a smartphone could be a powerful digital assistant if it had two things: really bulletproof synchronization of data we keep in our PC or on the Web, and quick retrieval of a specific piece of data from many megabytes or even gigabytes of stuff. These requirements are not adequately met by current smartphones, but a sophisticated database engine like MS SQL Server CE or SQLite (which is starting to look like a new cross-platform standard) can go a long way toward filling the gap. Relational data allows you to, well, relate bits of data to each other in ways that are difficult to do otherwise. The "tagging" mechanism utilized to great effect by GMail and many other Web 2.0 applications is a good example of how retrieval of information could be dramatically improved. But consider being able to search for a note you recall taking down the week before your last vacation (date queries) or all the documents, phone logs and emails that are associated with a particular customer in your Contacts list.

An interesting thing about the applications that Information Users most need is that they share a pretty uniform set of operations affectionately known among developers as CRUD (Create, Retrieve, Update, Delete). These operations correspond with the basic SQL commands such that the application logic itself can be a pretty thin layer on top of the database. Thin enough that this logic, and even the GUI, could in many cases be represented using nothing but data in a database and a middleware engine that takes the place of the code that the developer would normally have to write. We call this a pure data-driven architecture, and it has two very interesting properties that are relevant to the future of mobile data on smartphones. First, these applications are very easy and fast to create and modify since almost all of the difficult stuff has been coded into the middleware. Second, once the middleware has been certified and tested (and perhaps even included in ROM by the ODMs and carriers) the applications that run inside it are safe and reliable from the perspective of the carriers. They don't execute arbitrary code against the operating system since they are completely sandboxed by the middleware. Since the carriers are wary about native applications for the risk they believe they pose to the stability of the network and (more realistically) for the costly support headaches they can create, a data-driven service-oriented mobile architecture like this would probably be welcomed with open arms, as would the developers who take advantage of it.

The Mobile User Experience (MEX) blog has an interesting review of Yahoo! Go that reminded me how some mobile software lessons have to be learned over and over again. Here's an excerpt:

At first glance, the application looks great - intuitive interface, great integration between all the different features and a service clearly built from the ground-up for mobile, rather than simply re-hashed from the desktop environment.

However, I have found it to be almost unusable in real world situations.

In one instance, I had 15 minutes to spare on a train journey and wanted to find the location of the restaurant where I was meeting my friends. According to the marketing materials, Yahoo’s Go is ideally suited for this - it should be able to find the restaurant, show me a map and even offer directions.

In reality I found that even with 15 minutes of dedicated searching I received nothing but a sense of frustration from the application, let alone the result I was looking for.

At every stage of the process, the huge latency destroyed the user experience.

I cut my teeth as a mobile developer targeting the Palm OS, which was designed by a bunch of guys who were freakishly preoccupied with the idea that applications need to respond instantaneously to user input—faster even than what users expect on their PCs. Every developer that came to the Palm OS in the previous century was urged from every corner to meditate on the Zen of Palm, a wonderful article written in 1996 and still available here. Even if you don't go back that many years you may still recognize the name of some of the mobile computing greats in the list of contributors. A favorite passage (should it be called a verse? a koan?):

A handheld must be quick to use. A handheld is like a sports car because it gets the user from one place to another quickly. The actual technical specifications of a handheld are of little real interest to the user. What matters is how quickly she can reach for the device, open it, find the appropriate information, and proceed with her other tasks.... People use handhelds to do things—now!

It's worth remembering that all this talk about handheld computers being like sports cars was written when these devices had 16MHz processors and as little as 1 or 2 MB of RAM. But these guys are as right today as they were more than a decade ago: when a user is mobile they expect instant gratification. Mobility means you're in motion: you have other things you need to be paying attention to. Even if you're trying to be distracted by a game, a blog post or a video, when you're mobile you only have a few moments before the world calls you to rejoin it.

Many mobile developers seem to think that Moore's Law and 3G networks have obviated the need to think about responsiveness. I checked out Yahoo! Go myself and I can see that someone needs to send the product managers at Yahoo off to the monastery for a few months with a copy of the Zen of Palm. It's already tough to make an application usable if every time you navigate to a new screen you need a round-trip to the server. But if you're going to return everything that you can possibly think of that relates to a search term, including a lot of graphics and processor-intensive layouts you're app is going to be sloooow.

In this day of Web 2.0, SOA and Software as a Service, Sun's slogan "The Network is the Computer" has become the mantra for a generation of new software developers, so it's easy to understand how this "modern" way of looking at software has carried over to mobile. We may be getting close to this vision on the desktop, and some day we will be there on the mobile, but in my opinion we're not there yet. Mobile computing faces a chasm of usability right now that thin client and browser applications are not going to lift us over. Most people find the user experience of software on their phone to be unacceptable for anything but the simplest tasks. Smarter mobile devices will not gain mainstream traction until that problem is solved, so focusing on ways to get cool online services on peoples' mobile before you solve this problem can be putting the horse before the cart if you're not careful.

There are a lot of factors needed to fix the user experience. For now we are seeing that the best accepted applications still need a blend of local and remote storage, offline access to data, and efficient over-the-air synchronization. I've given my crazy talk about the UI elsewhere (and by the way, I'm happy to see Little Springs Design backing me up on this). But maybe we also need to think outside the box sometimes when we go to use the network. Do we always need to use XML as a data transfer protocol, with its large overhead in delivering and then parsing all those tags? Do we always need TCP connections, or can light-weight datagrams and a little error checking get the needed reliability without all the time-consuming handshaking? Some of this sounds like heresy, I know, and for some solutions staying safely in the box is the right answer. I'm not knocking standards or interoperability. All I can say is that if we're going to cross the chasm toward mass adoption of mobile computing (more than just voice and messaging) it's going to take some thinking that hasn't been widely done yet.

I don't have all the answers, but apparently having a name like "Yahoo!" doesn't mean you've got them, either. We've all got a lot to learn in this business. But let's not forget the hard-won lessons of our forebears. For the time being, the network is still sometimes just the network, and the computer, well, it's the computer in your hand.

Red Five Labs has released their implementation of the .NET Compact Framework 1.0 for Nokia S60 smartphones. This is a very cool development that holds out some real promise for attracting developers to the hugely popular, but somewhat application-shy S60 platform. Some salient points:

• They're releasing it with a no-royalties runtime. Perfect.
• It's the real thing: managed code, the CLR, Visual Studio 2003/05 tools, your choice of C# or VB.NET, binary compatibility with apps targeted for Windows Mobile
• They used some of the code from the Mono project for this. Don't be surprised if Linux platforms like ALP become their next target.

Some questions, though, which I hope to have answers for soon:

• Since S60 doesn't have a touchscreen am I correct in assuming this only works for apps developed for the Smartphone profile of Windows Mobile?
• How are they doing the GUI? To use an analogy to Java, are these Swing-like controls (living in managed code-land) or SWT-like controls that are proxies for native widgets?
• How soon before a lot of the stuff that was left out of .NET CF 1.0 is going to be added?
• How soon before this starts shipping in the ROM of an S60 phone?
• What about an implementation of SQL CE?

One of the things that still makes SuperWaba so compelling for cross-platform Windows Mobile and Symbian projects is that you have a simple, but serviceable no royalties SQL database engine. Plus you get Palm OS, Linux and Sony PSP support. Unfortunately, SuperWaba suffers from being almost invisible to developers and users north of the Equator. It's a real shame that someone with a little venture capital hasn't scooped that little company up and given their platform the treatment it deserves.

Thanks to Kevin Cawley at Newsgator for the pointer to this news. There's a company whose fledgling mobile wing is one to watch this year, by the way.

Motorola announced availability of the first mobile phone (that I know of) that uses an "electronic paper" display, similar to the technology used on some recent eBook readers like the iRex iLiad. The big win with putting these electrophoretic displays into phones is that they are dramatically less power hungry than the common TFT display found on almost all modern mobile phones. This is because they don't draw any current at all while displaying--only while the display is changing. The lower power consumption means you can use much smaller batteries (and get a smaller, thinner handset) and/or get a lot more life out of them from a single charge.

People who have seen these displays report startlingly clear, paper-like monochrome text. That's as long as you've got ambient light to see it, since they are reflective, not backlit like an LCD. The other downside is that electrophoretic displays currently take a couple of seconds to refresh. Perhaps that time is less with a smaller display, but it's an indication that these aren't yet suited for displaying multimedia or even for use in touchscreen devices.

Still, since battery technology is advancing at a snail's pace compared to every other component in our mobiles, it's encouraging that advances in display technology may deliver us from big, heavy, short-lived batteries before long.

Moto's new phone, released in India, is the first in it's new Linux-powered SCPL line, destined to replace the popular RAZR series. No FCC approval yet, so we may not see this particular model in the US for a while, if ever. PhoneScoop's got a review and more pictures.

I was only half-listening to the Chicago public radio station this morning on my way into the office when I heard the announcer say something that sounded an awful lot like "Concertino for Cell Phones and Orchestra," which naturally caused me to prick up my ears. Sure enough, turns out that there is a Chicago Sonfonietta concert this weekend that will include the world premiere performance of exactly that: a piece by jazz composer David Baker incorporating participation by thousands of mobile phones in both the orchestra and audience.

During the 15-minute composition, members of the audience and the orchestra will be asked to use their cell phones at various points throughout the piece with red and green lights telling them when to turn their phones on and off.

Baker, who has more than 2,000 jazz, symphonic and chamber compositions to his credit, said people will also be encouraged to randomly increase and decrease the volume of their ring tones and try to recognize familiar tune fragments on the ring tones sounding on orchestra members' cell phones.

What a cool idea! But I hope Mr. Baker has a team of geeks on board the project to work out the logistics. People in different sections of the audience are supposed to turn their phones on and off at certain intervals during the piece, but of course this isn't going to produce any sustained "ring tones" or enable the audience to adjust the volume at the direction of the conductor as the InformationWeek interview with the composer suggests--there will only be the brief "booting up" jingle that the phone vendor configures for the handset.

What the maestro needs to arrange is this: Audience members provide their mobile number before the concert and they are entered with their seat section (and no other personal information) into a database. There's a musician in the orchestra that we'll call the "mobilist" (the orchestra already has "cellists" ;-) whose instrument is something like a small organ console with a dozen or so keys that correspond to different sections in the auditorium. The console is networked to a server farm that's capable of placing thousands of automated calls simultaneously when a key is depressed. The server hangs up the call when it's corresponding console key is released. Maybe a second rank of keys on the console sends text messages to the phones for a different sound effect!

Well, that's how I would compose a concerto for mobile phones and orchestra! Unfortunately, I'll be back in Colorado when this is performed. Drop me a comment if you get a chance to hear this!

Update: It looks like there's actually a precedent for the idea I describe. The audio samples from that 2001 concert range from the ethereal to the bizarre (like when the conductor triggers the vibrator on one well-amplified phone in the audience in this MP3 clip). If you're interested in a technical diagram of how that earlier performance was realized check it out here.

If you haven't been over to MobileCrunch for the latest Carnival of the Mobilists, you really should get over there. Great job by Oliver.

Two of my favorite articles from the week didn't make the Carnival, though, and they're interesting to read together since they are both thought-provoking impressions from CTIA. Daniel Taylor at Mobile Enterprise Weblog says "CTIA's smaller fall event is nominally about the enterprise, but CTIA's focus is really the wireless operators" and shares this anecdote:

I called a friend who's an IT managers and asked him what he thought about flying to LA to attend CTIA and EnterpriseNOW. His first question was, "who's speaking?" When I sent him to the website, this is what he said:

I spend my day trying to wade through this B.S. Do you think that I would honestly spend several days of my time plus travel budget to go hear a bunch of vendors tell me about my business? My biggest challenge is getting the slideware to fit into my daily operational requirements. And if you want me to show up, put a bunch of my peers on the schedule, have them speak and then give us the chance to get together and put the carriers in the hotseat.

Meanwhile Mike Mace compares CTIA to the Future of Web Apps show in San Francisco and sums up CTIA as "sleepy." By comparison, the FoWA show was "sizzling with energy." Mike sees what a lot of us in the mobile software market are seeing: the wireless carriers are trying to capitalize on the mobility trend by channeling as much of it into their controlled domain as they can. Elsewhere--especially on the web--businesses are capitalizing by innovating. The carriers won't be able to keep this game up forever.

There's a collision coming between the wireless world and the web, and I think it won't be pretty. The best way to describe it is by analogy. Picture a raging river fed by the meltwater of a hundred glaciers. The jagged river valley is suddenly blocked by a dam. What happens?

Go read it for yourself.

I didn't make it to CTIA this month, and in a way I'm almost glad I didn't.

First off, my apologies for the long silence here. It's been death march time for Pikesoft's biggest client which means lots of 10- to 11-hour days plus Saturdays as we start a rolling beta cycle that will end in a release to literally tens of thousands consultants. The first beta is to a much smaller group, but politically it's hugely important and it's been hard for me to think about anything else, much less blog about it. Finally, the CDs are being burned and I'm looking around to see what I've missed during the last two weeks (aside from sleep and days off).

Lots. But let's start with this little item. My good friend Jeff Duntemann (maybe best known for his classic primer on assembly language and a best-selling book on Wi-Fi) stumbled across a telling development in wide-area broadband wireless that's taking place in the small city of Pueblo, Colorado, just 45 minutes south of us. There, in a booth at the Colorado State Fair was the CEO of Airinet, a local ISP that is rolling out a Wi-Fi mesh network big enough to cover pretty much the entire city of Pueblo, with a population of a little over 100,000. These guys have come up with a tiny, super-cheap Wireless-B mesh node and a router system that they claim is efficient enough to deliver 1.5MB download and 1MB upload to clients that are as many as 8 hops (!) from a backhaul point. No towers for neighbors to complain about: they negotiate with homeowners to stick the unobtrusive repeaters under their eaves. No hardware to install to get service: it's 802.11b that any PC, PDA or Wi-Fi-enabled mobile phone can connect to indoors or out. No long term contract: unlimited access is a flat $25 month to month. Also never an insecure connection: the channel is encrypted with a 2,048-bit key. Best of all, no walled garden! Just a nice big pipe to the Internet anywhere you go in the city.

Mesh networks aren't terribly new. As Jeff points out, they have been used to unwire college campuses and for the odd municipal wireless project--mostly non-commercial stuff. Google is using a mesh architecture to deliver Wi-Fi throughout its hometown of Mountain View. But these are not Google engineers and this is not Silicon Valley. This is a mom-and-pop ISP in a small, blue-collar city with a median household income of about $30,000. If Airinet can make money today with a mesh Wi-Fi cloud over a city like Pueblo it raises some interesting questions:

• WiMax, the technology that was supposed to make this kind of thing possible is still by most accounts some years away for most of the US, so if mesh networks are low cost and ready for prime-time, will they steal the WiMax thunder?
• If a little company like Airinet can do this are we headed for another era of garage-ISPs, this time hawking ubiquitous wireless connectivity?
• If small commercial wireless meshes can make money with unlimited broadband at $25/mo, how long will the cellular wireless carriers be able to sell slower connections to walled gardens at two or three times the price?

Like a lot of mobile developers I'm fed up with the carriers. It's a bad business model when you need to sell through a channel instead of direct to the customer, especially when the channel has the controlling mentality that the network operators have today. If they get their way the era when users can buy shareware off your web site and install it on their phone will soon come to an end. Native apps will have to be approved and digitally signed by the carriers themselves, will only be available from within their walled garden portals, and will return little of the purchase price to the developer. If they succeed, mobile innovation will lag far behind the Internet speed of Web 2.0 and mobile developers will move on to greener pastures. But if small companies like Airinet can do an end-run around the wireless oligopoly things could play out quite differently. The carriers aren't going away--mesh networks won't offer nationwide roaming any time soon and the VoIP story is unclear. But for local wireless data the carriers won't be the only game in town and this could shift the competitive landscape in a direction that opens some nice opportunities for mobilists like us.

Microsoft has followed through on an idea they introduced at the World Economic Forum in January to bring PCs to the poorer people of the world: developing a mobile phone that doubles as the CPU for a modular computer system. You plug the phone into an ordinary TV and a keyboard, and then have access to the web, email and simplified office applications. Called "FonePlus," it runs Windows CE and is still basically a prototype.

This is similar to the idea I suggested a couple of weeks ago as an alternative approach to OLPC's "$100 laptop." But it's aimed at a higher income level because it presumes users have electric power and televisions in their homes. That's not necessarily a bad thing. One thing I was amazed at when I lived in Mexico back in the mid-80s was the number of people living in dirt-floor shacks who nevertheless owned televisions and had satellite dishes in the yard. They studded the landscape almost like a field of mushrooms, even in the poor outskirts of Mexico City.

But if you want to reach the poorest of the poor--those for whom communication of information against political, geographic and economic obstacles is the most critical--challenges like the absence of power infrastructure must be addressed. To the MIT Media Lab's credit, OLPC has given this serious thought. I just wish they had considered a way to leverage the familiar mobile technology and existing infrastructure rather than whisk in with something that for all practical purposes is "alien technology."

But Mike Rowehl offers an important contrary perspective, questioning the wisdom of pinning hopes on mobile technology to bridge the digital divide while the wireless operators control the game. Like me, Mike believes that for software solutions to make a difference in the developing world they must be locally developed. But that requires a reasonably open platform that so far few mobile operators have allowed to exist:

Before I thought things through that way I had said the same thing... that the OLPC project should be using handsets not laptops... seemed obvious. I would like to publicly retract that statement. Cellular networks are a horrible place to try to build new, novel, well-situated solutions. The networks and hardware are not open, the communications subject to regulation and restrictions, and the solutions fundamentally tied to someone else's business model. Fuck, experienced entrepreneurs in developed countries can’t manage to get their applications out. If we really want to help out other countries in terms of building out their infrastructure do we want to lead them into tying their solutions to carrier networks? Do we want them forced to do Symbian C++ programming if they want access to non-JSR mediated functionality? Should they need to have to send their handset in for test enablement before they can try to use their own apps on real hardware?

Regretfully, I have to admit that he's got a pretty good point. While money and device volume of the kind that OLPC is working with could be used as leverage against the operators to allow the release of phones on a more open platform, you have to wonder if even this would penetrate the narrow logic the operators work under. They're already making good money in places like Africa without taking a "risk" on handsets with open platforms. But I'm not as pessimistic as Mike that wireless business models and social necessity need always to be at odds. For one thing there already seem to be some pretty remarkable cases where necessity and profit have aligned in this area.

Several members of the OSGi Alliance--Nokia, IBM, Samsung, ProSyst, and Gatespace Telematics--have removed a barrier to the adoption of the OSGi component architecture standard by pledging to allow royalty-free implementations of the OSGi service platform. What this basically means is that any mobile platform vendor can implement the OSGi standard in their software and not have to worry about being sued for infringing patents these companies hold in this area. It's an extraordinary step that should accelerate Java ME's transformation into a much more powerful, flexible, and manageable mobile platform.

Peter Kriens blogs about the new patent pledge and makes a good case for using OSGi middleware with Java ME. You can learn a lot about OSGi from his blog, although some of his focus is in some of the more mature areas where it's been adopted, like telematics, and not so much in mobile phones, which is where the biggest opportunity lies.

I'm a firm believer that a standard component architecture is one of the things most needed for mobile computing to reach its full potential, and agree with Peter that OSGi looks like the best game in town now. Mobile applications need not just to be able to share libraries but to do so in a loosely coupled framework that enables remote addition or updating of modules without interupting service. This will enable much more sophisticated mobile applications to be assembled from plugins by different developers--the model that has made the Eclipse platform take off like a rocket. And that's exactly what OSGi makes possible.

First, props to Michael Mace at Mobile Opportunity, who took a clever and creative approach to his mission as host of the 37th edition of Carnival of the Mobilists. I continue to be impressed both with the quality of the writing that makes up the Carnival and the dedication of the hosts to making it a great reading experience instead of just a list of links. I look forward to reading it every weekend. Also a big thanks to Khosla Ventures for sponsoring this great community.

I always like to call out my own favorite contribution to each Carnival but this week I have to agree with Mike's choice. Steve Litchfield and Rafe Blanford's point/counterpoint debate about what (if anything) should be done about the limited usage patterns of smartphone users gets right to the heart of what all of us in the mobile software business are trying to understand. Writing as they do for AllAboutSymbian.com, they use the example of the Nokia/Symbian S60, which is the most popular smartphone platform in the world today by quite a long shot. While from my observation Palm OS and Pocket PC phone users are more likely to use the applications on their phones and to install third party software, the basic and surprising fact remains across all smartphones today: people are buying them but most aren't using them very differently from simple cameraphones and feature phones.

With Rafe I count myself among the optimists who believes mobile applications will become mainstream before long. Rafe writes:

the 'killer app' is customisation and while people are used to achieving this just though content (themes, ringtones, Java applets, etc.) in time it will be second nature for it to be through services and applications. The change is not educating people that this is possible, it is changing their thinking that this is the way it should be. i.e. part of the reason for non take-up of third party applications is an expectation that a phone is a phone. Early computers were seen as advanced electronic typewriters for many, but clearly this was an under-sell...

Mike himself had a good discussion a while back of how to give users the vision that they can personalize their devices with apps, not just ringtones and skins. He calls for a new software platform that's designed to query the user about their profession, hobbies and activities, suggest applications that might interest them, and link them directly to a store to download and pay for the software--all on the smartphone screen. I'm down with him 100% on the need for a new platform and that application discovery is the critical missing ingredient, but I wonder if we couldn't do even just a bit better than what he describes.

How to teach someone they really need a smartphone

The experience I'd like to see when someone turns on their smartphone the first time is something like this: First the phone should ask the user to plug their cradle into their PC and drop the phone in the cradle. The PC should recognize a partition of the phone's flash as an external drive and should auto-run a PC application directly off device memory--don't expect users to run a CD. That application becomes to your smartphone what iTunes is to your iPod. There on the large screen with a fast, unlimited Internet connection, is where you query the new user about his or her interests and sell her the appropriate software.

There are a couple of reasons for doing it this way. First, if you know the users you're reaching out to are the ones who aren't accustomed to using mobile applications, don't try their patience by confronting them right out of the box with an on-device customization application that requires a lot of tapping and tedious touchscreen entry. To do a good job personalizing the device I think this application is going to need to get a fair amount of information, which probably would be easier and quicker to do on a large screen with mouse and keyboard. It also needs to be revisited regularly. In addition to being easier to navigate on a PC, the discovery experience can be richer and more immersive there than on the tiny device screen. Mike talks about the Expert Guides -- user-generated web content that PalmSource published so that people with specific professions, hobbies or activities could get software recommendations from like-minded users that had tried a lot of software already. In the Web 2.0 era that kind of content shouldn't be posted in static web pages, it should appear in communities that new users can browse and join. Like Amazon does, the desktop companion software to any smartphone should keep tabs on the communities that users have visited or joined and the software titles they have visited or purchased and offer suggestions of other titles they might like.

What made the iPod sell so well despite there being a fairly mature field of personal music players on the market at the time it came out was not the device itself. iPod sales didn't take off until iTunes was released on Windows. That should be a hint to everyone involved in trying to sell smartphones and the mobile computing vision: it takes more than nice hardware and a good on-device user experience to sell mobile data; it takes an end-to-end solution that's focused on helping the consumers in the Long Tail of the software market discover the niche applications to personalize their devices.

This companion software needs to be a powerful tool in its own right as well as a way to discover new tools. For one thing, if it's going to be used to attract "eyeballs" for marketing purposes you need it to be something people want to look at on a regular basis. It really should be the replacement for tools like Palm Desktop and Nokia PC Suite in that it should give you at-your-fingertips access to the data and apps on the phone from the PC. But one important difference is this: I propose that even the PC software should stay in device memory rather than be installed on the PC. This might sound very strange but it has some powerful advantages, despite the cost of the extra flash memory. It makes it so the user can access their desktop companion software from any PC at all--they only need to connect their device to it via USB, WiFi or Bluetooth. It also means that the sometimes time-consuming (and slightly nerve-wracking) process of synchronizing data can go away completely. Aside from backups (which can occur silently in the background whenever a device is docked) all your data is in one place: on your person wherever you go. The era when mobile computing will really take off is the one when people start to think of their mobile device as the place where their whole personal workspace and playspace live and the PC is an accessory that just lets them use those spaces in a more immersive, less peripatetic manner.

This gets back to the topic of continuous computing that I discussed in my last post. I've got a lot more to say about this, but it will have to wait. Suffice it for now to say this: if you think people don't need smart mobile devices, just wait. They said people didn't need home PCs either.

My injudiciously titled post "Forget the $100 PC" drew the ire of Nicholas Negroponte supporters after Robert Scoble blogged about it Sunday. I say "injudicious;" David Rothman preferred the term "moronic." So, I thought I'd extend an olive branch today and explain a little more what I meant when I said that cell phones are already delivering on some of the promise of $100 laptops for the developing world and should be tapped to deliver a lot more.

I very much like the goals of the One Laptop Per Child (OLPC) program and I like many things about the prototype laptop, too. As I hinted vaguely at the end of that post, my misgivings about the program are less about the technology than about how it is to be introduced. With the plan being to produce a breathtaking 15 100 million of these computers it makes me wonder how much time is going to be spent educating and building support in the grassroots for the idea. Branko Collin summed up my concern when he said:

Don't para-drop these things. The OLPC needs to be a 99.9% local project to succeed. Currently it seems to be largely a Western project.

How do you do that, though?

It seems to me, a good start for turning OLPC into a homegrown project is to leverage the homegrown (or at least well-established) computer use that's already there. And yes, mobile phones, which are deployed even more broadly in the 3rd world than they are in industrialized nations, are a fairly powerful computing technology--even the cheapest ones are. They just haven't been used that way very much. Yet.

Of course, laptops and cellphones are very different things. The "converged" phones that blur the boundaries are out of the price range of even most Western consumers and still not much like a laptop. Even so, I can see low-cost Java-enabled mobile phones soon being powerful enough to use as the core of a modular PC-like computer system. In looking at this possibility I don't want to take away from using mobile phone software that runs only on a phone screen to improve access to computer technology in the developing world--this is the first and, to me, most obvious opportunity that is ripe for the taking today. But I do want to explore what might be the next logical step: inverting the relationship of the PC and mobile so that the PC becomes a display and input accessory for the device.

Products like BlackDog and airWRX are on the right track with pocketable, "always-on-you" computing environments that blossom onto an available screen and give you use of a keyboard and mouse when they are connected. Integrating this capability into the design of a mobile phone isn't technically difficult or costly: mainly it requires a good chunk of flash memory, a USB port, and the right software.

For example, Nokia S60 phones already support running a scaled-down Apache web server that could serve up web apps and eBooks to one or more thin client terminals--albeit through a WAN gateway with network data charges, not local USB or Bluetooth. The next version of Java ME (MIDP 3) will enable even the cheapest phones to run MIDlets in server mode. Network Improv's airWRX project takes this inversion of client and server in the right direction: serve up rich SVG applications from mobile devices to desktop terminals connected by USB or personal area network. Liam Breck at Network Improv calls this "continuous computing":

Achieving continuous computing requires a means to carry your apps & data with you at all times, and engage them via whatever devices are available. The flash drive [or mobile phone] application server delivers that; current systems do not. PC architecture binds apps to a single powerful unit, which is generally too bulky to carry continuously. The alternative of siting personal apps & data on the internet hasn't caught on because it requires costly managed hosting and a network vastly more accessible and reliable than the internet is today.

It seems like using a mobile phone in place of a flash drive as the application server site would make continuous computing a practical idea for the kind of people OLPC is hoping to help. In fact, there are several reasons why this approach might be a better way to do the $100 "laptop":

1. Mobile phone distribution and use already works in the 3rd world. Good old fashioned capitalism seems to be doing the trick here. There are hundreds of millions of handsets, active markets for wireless minutes (a street-level retail trade that itself has created a lot of economic opportunity) and wireless infrastructure and coverage that is already surprisingly good. This is a good foundation on which philanthopy can build up the technology--whereas laptop PCs are new, unfamiliar, and probably less in demand.


2. Mobile phones have broader uses than a laptop. Improving personal communication in the developing world is at least as important for economic development as improving the education of children. Penetration of mobile communications has been directly correlated with economic development and the disempowerment of despotic regimes, both of which feed back into education, health, and social stability. Personal devices one wide-area networks have the most leverage because they empower you wherever you are, not just at school or in your home.
   
   I admit that the multi-use aspect of a cellphone can be a problem if the children need the computer for their education and Dad needs it to check the market and figure out what he's planting. On balance, I'm inclined to think that's a problem that arises from success, which is better than the problems that arise from failure. It means people need more and cheaper phones, not that modular computing centered around the mobile phone is the wrong solution.


3. Laptops are monolithic and notoriously costly to repair or update. With a separate screen/docking station, keyboard, mouse, and CPU (the phone itself) we have a componentized product that can be more cheaply repaired or upgraded. Think long term.


4. A modular system enables one screen to support many personal computing environments. No matter how many computers OLPC is able to distribute, there will be a demand for more, even within a single household. If peoples' data and applications are housed in separate modules that they carry with them (their phones) it's easier for them to share the other hardware. This practice aligns well with how Africans already share technology within a village or neighborhood.


5. Content on a phone can be used when you're mobile and can't be sitting in front of a big screen and keyboard. If you travel much in the developing world you know that people spend a lot more time waiting than we do in the industrialized world. You wait in line. You wait for the bus to get you somewhere. You wait for your parents. You wait for something you need to arrive so you can be productive again. If a lot of your "stuff" is available to you on your phone--even if you don't have a great screen and input capability--you can recapture those long expanses of time. You can read an eBook or play a word game to practice vocabulary. I'd go so far as to suggest that mobile computing makes a bigger difference to people living in a place like the Congo than it does to your average roadwarrior in the US. Even if the "user experience" on a small screen and a 12-button keypad is not up to the standards of Treo-toting Westerners.

To pull together and distribute a modular computer like this, OLPC would need to work with the wireless operators to solicit bids for the production of phones that have the right specs, software, and connectors to work with the other components. There's a precedent for this kind of deal, as Motorola won just such a contract to supply 6 million $30 phones for the African market last year--and made a profit from it, by the way. OLPC should purchase the phones they need for free distribution in the schools along with the other components, but the phones and other components should also be sold on the open market just as mobile phones are today in these countries.

OLPC should also work with the operators to provide free over-the-air software updates and content. I haven't read anything about what OLPC hopes to do in terms of getting software into people's hands, but the fact that mobile phones are connected to a wide-area network makes the prospect of delivering and updating software a more manageable one, if still one that requires a lot of thought and innovation to make it simple. This technology is still cutting edge and an endeavor like OLPC could really give device management standards like OSGi a boost.

My overly dramatic taglines notwithstanding, I like the idea of the "$100 PC." I love the things I hear about the innovative display technologies that Negroponte's team has developed. I think the hand-crank recharger is inspired. Both innovations would be part of the modular solution I would put forth. Furthermore, I admire Mr. Negroponte for his insistence that what the developing world needs is the best technology, not warmed-over day-old computers from the West. With the developing nations actually being pioneers in the usage of mobile phones for banking, payroll, and virtual debit cards, I see an openness to push the envelope there that makes it a natural (if surprising) place for the cutting edge to meet the real world.

The Carnival is in town today, so grab a pitcher of cold lemonade and head out to your virtual porch swing to watch this week's parade of mobilists. A big note of gratitude to Carnival host Debi of MobileJones for selecting my post about the impending era of mobile mash-ups as her favorite. (blush!)

I noticed that Judy Breck at Golden Swamp picked up on the same "cell phones in Africa" Washington Post piece that I commented on a couple days ago. And I really like where she is going with this. She asks:

Do we realize that by putting a cell phone with a keypad into [a Congolese woman's] hands we have given her a tool for practicing and rewarding literacy itself? Perhaps not every Congolese (and/or the other billion+ people in developing countries who now have phones) will become literate by using them. For sure some will.

Suggestion: incorporate language practice applications into the phones. This is a stunning new way to reach remotely located people with literacy lessons! Let's do it.

It's striking (and somewhat amusing) to me that we have Nicholas Negroponte grabbing the spotlight with his grand plans about distributing millions of $100 PCs to children in the developing world while behind his back a more dramatic and broad-based deployment of wirelessly connected computers has taken place without the help of MIT's engineering genius, thank you very much. Cell phones in Africa cost on average about $40, have 152 million subscribers (ten times what Negroponte hopes to deploy), and are more ubiquitous than even that number would suggest--97% of Tanzanians say they have access to one, for example. These devices are used not just for voice and messaging, but for banking, purchasing consumer goods, obtaining critical market price information, getting medical care, and even implementing government policies like weapons buy-back programs. People understand the value of mobile data there as very few consumers in the industrialized world do. Most of these phones have Java MIDP environments in them that are quite capable of delivering useful, even life-changing, mobile content and software of the sort Judy is hinting at. She and I have been sharing a brain wave this week, I can tell, and it's really started me thinking about mobile software in a different way.

Give me a large enough lever...

It's as if I'd been hiking around with a favorite walking stick for years, dislodged a large rock as I walked one day, and... Eureka! That comfortable old stick is not just a helpful thing to lean on any more, it's suddenly a lever that can move objects much bigger than I am. Here in America the power of a mobile phone is a useful convenience that makes navigating a busy modern life easier and more pleasant. We say we couldn't live without one, but it's a figure of speech. In a place like the Congo, on the other hand, it is a tool that bears powerfully on some of the most threatening and difficult to solve problems of the developing world: poverty, malnutrition, economic participation, the fight against infectious disease, access to education, humanitarian relief, even the spread of armed conflict. I'm not being so naive as to suggest that these ageless problems admit to a quick technical solution that oh-by-the-way just happens to be in the area of my technical specialty. But when I see the problems that mobile technology is already helping people solve, it makes me wonder: could we mobile software developers make a difference--a real contribution to the world--if, just for a while, we looked closely at the problems of the developing world instead of focusing on our own comparatively small ones? Is that big lever right in front of our noses?

For the moment I'm going to leave that question hanging in the air. All I want to add is this: Africa has long been a favorite place for the West to implement utopian foreign aid schemes. Most of these have been driven more by the rhetoric of guilt than realism about the kind of aid that actually helps rather than making things worse. (Did I mention that one of the two Ph.D. dissertations I never completed was on development economics?) I'm not saying that 15 million $100 laptops for the developing world is a terrible idea. But if you really want to know what people need, look at what they reach for without your help and consider how you can enhance that first. Right now what people are reaching for in Africa is not a laptop. It's a cell phone.

Go to my follow-up of this post: "A better $100 laptop"