Yahoo Mail Supports Free IMAP … But Only via Mobile

It’s hard to know what to say about Yahoo at this point. They have a lot of page views, but their internal organs seem to have been liquified from the inside by some flesh-eating plague.

Barely alive, they are of course responsible for their own continuing undoing. A great example is the failure to do something useful with the email user base. The purple crew has missed every opportunity to exploit the email product, from Google-style ads to Facebook-style social networking (back when they had a chance). And there’s the infamous CEO with her Napoleonic airs.

But I digress.

See, here’s the thing. On the Internet, unless you’re lucky enough to be a telco, you actually have to compete. Which means when Google gives away IMAP-enabled mail, and Windows Live gives away POP access and 25+ GB of online storage, you need to rethink your strategy of making your mail product harder to use while praying that the nine people on earth who haven’t heard of Google will sign up for your deluxe mail service (now with undercoating!)

But Yahoo has never been able to think one thing at a time. It’s not so much that they excel at multitasking than that they are schizophrenic. So while one group is committing ritual suicide with the email product, another realizes that to reach the mobile market, exposing mail via open protocols might help.

And hence they offer endpoints called something like imap.mail.yahoo.com and smtp.mobile.yahoo.com. Before you get all excited and ask me to check the hostnames and port numbers, though, I’ll drop the punchline: it appears Yahoo filters access to these services based on IP, and opens the service to mobile carrier address blocks (and carrier proxy addresses).

After seeing my phone successfully configure itself for these services, I couldn’t resist trying them from a desktop client. No joy. I guess if I were really hardy I could grab the public-net-facing IP address for my phone (by having it connect to my own server) and pretend to be that IP. But … really … is it worth it? No… with Yahoo still living in 2002, I’m afraid it’s just not.

AT&T “Fixes” My Phone by Downgrading It

I don’t want to be another corpse in the AT&T pile-on. AT&T has many problems, and they impact me, but let’s look at another technical clue about the network trouble:

I stopped in Tuesday at an AT&T store to see if they had any advice or fixes for the network issues plaguing my phone. The only thing the service rep said he knew of was to replace the SIM card. Sure, why not? Can’t hurt anything, can it?

Well the answer to that question apparently depends on whether ditching 3G access counts as “hurting.”

Since I got the new SIM, the phone spends most of its time on the EDGE and GPRS service, and only rarely gets a fix on the 3G service even when I’m in known-good 3G areas.

For a fleeting moment, I thought about taking the phone back and asking AT&T to do something to restore my 3G goodness.

But I quickly realized that the network’s inability to keep the phone on 3G was a big part of the problem. In other words, as so many iPhone users have discovered, staying on EDGE is better than flitting between EDGE and 3G and getting nowhere. Likewise in the case of EDGE and GPRS.

So for now, I’ll take my retro GPRS and its 50kbps or so of throughput. Since the setup and teardown of the data connection, as well as the latency in repeating a request, are the slowest part of the process, I’d rather use dependable 50kbps connection over an unstable, unusable 500kbps one.

Until I get a network that actually works, that is.

iPhone and Palm Pre – the Obligatory Post

I’ve had my paws on the Pre, and while I have not, of course, gotten hold of a 3GS, it doesn’t really matter.

See, getting my hands on a 3GS might convince me it has a better hardware/software experience. And since the 3G already has a better hardware/software experience than the Pre, I’m going to call it a “gimme” for the new 3GS.

The Pre, for all of its clever conceits compared to most phones, is still clunky, hiccup-y, and jittery next to even the current iPhone model. The graphics aren’t as smooth, the UI is harder to use, the physical keyboard is marginal, and on and on.

On top of that, it is hard to overstate how important the app ecosystem is to this “competition,” and Palm doesn’t even seem to be trying (they’re still saying “real soon now” on the SDK).

No matter how many apps in the App Store are just fart apps, and no matter how beautiful the bundled apps on the Pre are, there is no contest because these guys are playing different games.

Apple has succeeded in making the phone a general computing platform in the mind of the public – something I argued for 3 years ago – and you judge a platform not by its internal specs but by what you can run on it. Palm doesn’t seem to get that. They’ve got a decent bundle of specs but there’s nothing to run on it and there may never be much.

So with Apple still killing in the UX department, and Palm leaving their A-game at home (if they ever had one) as far as the app/platform/dev community goes … is there anything positive to be said for Pre in this contest?

Only this: AT&T’s network is so egregiously ill-behaved in so many prime metro areas that Sprint could actually pull a few people across the line.

I am one these last folks: I would much rather replace my current phone with an iPhone, but the thought of another two years of dropped calls, missed calls, bars-but-no-coverage, data connection unusable half the time … and I’m seriously considering the Pre.

Say what you will about Sprint (I’ve used every major carrier and none is perfect), where they have coverage, the devices just work. You can make or take a phone call. Which, ironically given that smartphones are bordering on augmented reality nowadays, is still the sine qua non for a phone.

Way to Compete, Guys…

Microsoft’s app store … sure, why not? But that’s not the bit they need to take on Apple.

Microsoft and the smartphone is really a funny/ironic/sad story depending on who you are.

They had a true next-generation mobile OS starting back in ‘01 … It was really easy to code for – like GUI-builder, point-and-click web services, run-your-regular-.Net-code easy. And they were outselling pretty much everyone in total device count a couple of years later. By ‘06 they even had consumer friendly devices, in the Moto Q series and then the Samsung Blackjack. They were poised to challenge RIM for the big shiny belt.

And then Apple came along and wiped the smirk off everyone’s faces. What’s surprising is that no ‘softie seems to have circulated an “Internet Tidal Wave” memo about mobile. Or, if they did, no one paid any attention.

In the last two years, we’ve seen a continuing proliferation of Windows Mobile devices, but no fundamental change – or even speed-up – on platform evolution. If anything, we’ve seen a slowdown, as Mobile 7 devices seem to be at least a year away, and the “app store” is going to launch on Mobile 6.5

In case anyone didn’t already notice, v 6.5 is a great OS if it’s 2005, but a non-entity in the iPhone era. An app store? well, maybe … but a store by itself has never been the magic sauce in mobile (remember Verizon’s “vending machine”).

And with a “logo validation” scheme for each app? Developers violating the logo cert guidelines is not the problem. The problem is that there are too many different form factors for Win Mo devices. Used to be, practically anything could run the OS. Around the 5.0 era, they reduced the number of supported screen configurations, and a few other things.

But there appears to be little escape from the compromise Microsoft made to be successful on the enterprise side: it’s really easy to code a simple utility/productivity/line-of-business app that will run great on almost any Windows Mobile device. And it’s equally hard to write anything really cutting edge, because there is simply too much variation in device capability and performance, and that genie's not going back in the bottle.

Perhaps Microsoft’s best chance lies in forking a “consumer” mobile OS, with stricter controls over the handsets. On the other hand, Apple is clawing into the enterprise, so an artificial separation of consumer vs. enterprise offerings may be hopeless at this point.

Adobe and Microsoft Get Into It Like Children on the Playground

A week or so back, Adobe exec Mark Garrett got a bunch of attention for insisting that Microsoft's Silverlight effort has "fizzled."

Microsoft promptly screamed back that it wasn't so, pointing to the inauguration video stream, and a few other factoids.

What makes this truly schoolyard funny though is what happened today when Adobe "announced" it was bringing Flash 10 to phones. This seems just as dubious as Microsoft's oft-repeated plan (since as far back as '05, when it was WPF/e) to get Silverlight onto mobile phones ... by last year ... which obviously didn't happen.

Meanwhile, for years, Adobe has been pushing a weak technology called FlashLite for mobile ... and for a variety of reasons it has never been a usable option for content providers to deploy Flash content or apps.

For both Microsoft and Adobe, for both PC and phone applications, the critical metric is current "content-ready" penetration. How many devices are ready to run new Flash/Silverlight content off of the web today.

In this 2x2, the only square that's solidly covered is Adobe's Flash on the PC. "Ready" penetration of Flash 9+ is near 100%.

On PCs, existing install base is critical because of locked-down corporate networks that won't allow end-user installs. Microsoft needs to stop talking about download numbers, or numbers of people who "can access a PC with Silverlight," and start doing anything it can to get these ready penetration numbers up.

On mobile, the barrier is user confusion over configuration. Vendors could push the updates to phones, but in nearly 10 years of smartphones, only Apple has done much of this. Windows Mobile 6 has an updater ... and in over a year I don't recall it ever updating a darned thing.

Flash Lite trumpets a large "installed base," but these are strange installs, where the runtime (but not browser integration) is baked into the phone, and there's no reasonable way to get new Flash content onto the phone, either via web pages or download.

Both of these players are big on bluster and have been for a long time. Meanwhile, developers are left with few options for all of the smartphones in the world that don't an apple on the back.

Time for a Wireless Coverage Map that Shows Utilization, Not Just "3G"

It's easy to get distracted with mobile protocol (HSDPA vs. EVDO) or "generational" system (GSM-3G vs. EDGE) speed claims. In fact, that's the most common conversation that mobile operators, hardware manufacturers, and customers have.

But it's only a piece of the puzzle. The other big ones include latency (the time required to establish a connection and get the packets flowing) and congestion (the instantaneous demand for bandwidth relative to the current capacity in a location).

Not to downplay the value of 3G+ data speeds, it is still instructive how well a "slow" connection can work when congestion is low, and how badly 3G can work when congestion is high.

Apple iPhone customers have complained about the high congestion experience. The other day I had an interesting low congestion experience.

I was in a corner of San Rafael where my phone could only negotiate GPRS -- but I had the air to myself. Subjectively, the browsing experience was better than a typical EDGE connection on the same hardware, and similar (for modest amounts of data) to the 3G experience.

Demand on the network changes constantly as users do different things, and the effective capacity changes due to everything from weather to RF interference to upstream network congestion. So it's not easy for an operator to make a priori statements about actual speeds or actual congestion ... hence they talk about the protocols they offer and their "optimal throughput."

But congestion/capacity issues are a first-order concern in many areas, so I propose some mechanism be created so that customers and operators can have an informed negotiation about service.

I'd like to see a coverage map, for example, that doesn't just show "3G" areas in a certain color -- but also color codes the average real utilization over the past 90 days. Sort of like shopping for an airline ticket and looking at that column that shows "on-time percentage." It lets a customer separate the hypothetical performance from what can actually be expected.

That information would also motivate operators to invest in capacity and infrastructure where the demand is, rather than trying to extend that "patch of orange" on their coverage map to one more town for sales purposes.

TextMarks and AppEngine Make Building SMS-Enabled Webapps Simple

TextMarks has been on my radar for a little while. It's a company offering free (ad-supported) access to SMS shortcode 41411, via a secondary keyword of your choice. They also have pro options with no ads, and shorter (or reserved) keywords.

Not having a great idea for a SMS-based app (I think I'm biased from having web-enabled, push-email PDAs for too long), but wanting to kick the tires, I decided to build an iteration of the now-classic "to-do list" app.

Meanwhile, I've been spending a little time with the Google AppEngine. When a hosting account came due for renewal, I decided to see if I could replicate it using AppEngine. AppEngine covers all the basics, and makes it easy to stream BLOBs out of the datastore as well. But if you host files (anything over 1MB), those are not allowed in AppEngine, either as static files or as datastore objects. Too great a magnet for bandwidth or data hogs I suppose. So those files live somewhere else.

But AppEngine makes a fine place to put a small SMS-driven app (assuming you don't need the background processes or scheduled processes that AppEngine doesn't allow).

Registering a TextMark is simple. Set the URL to the one you want called when 41411 receives your keyword, and add dynamic data from the SMS into the URL request GET params using escape sequences (e.g., \0 means "the whole message after my keyword"). So your URL might look something like http://foo.appspot.com/sms?text=\0).

Go into the "Manage" tab, pick "Configuration" and turn off the various options related to "posting messages" -- these aren't necessary for your app. If you aren't planning to asynchronously send messages out to your users (hard to do with AppEngine, as mentioned above), you can also turn off the subscription options.

Now you just need a handler on AppEngine to receive those calls and do something. Whatever the handler renders will be truncated and sent back to the user as a reply SMS, so you get a semi-web-like mechanism for confirming that you're done an operation, or returning results.

Create your AppEngine app, a handler, and yaml that ties 'em together, per the tutorial. Now you can just modify the basic HelloWorld to do your bidding instead.

Here is my little memo handler -- it files memos under the phone number of the person sending the text, and forwards a list of all the memos to an email address if it receives the command "export (email address)." Don't put anything private in there, since there's no PIN/authentication (although it would be easy enough to add) ... so anyone who knows your phone number and can build a URL by hand can just ask for all your notes :)

Of course, it's easy to test out your handler with just the browser address bar, but TextMarks also provides a nice emulator so you can send messages to your handler -- and see what the response will look like with their 120 char (free account) limit and their ad tacked on. And there are a bunch of other neat things you can do, like create short term stateful contexts, where a user can just text back Y/N or a response to numbered "menu" and the messages will get to your app automagically.

zBoost Cell Extender: Refinement Post

This is a refinement, or follow-up, to my first post about cell signal boosting with zBoost:

While the base station allows decent communication over a specific area once a data or voice call is established, it seems to have little or no ability to propagate the signaling part of the GSM protocols when there is no connection established.

This symptom means that the network is unaware of a handset, and a handset thinks there is no service. As a result, it often will not even try to make a call.

Once the handset decides there's a network -- usually by picking up a very faint signal from a real tower -- it will attempt the call and then discovers a near-perfect connection.

zBoost may not be responsible for this behavior -- the product docs specifically say that you have to have some real signal level in order to use the repeater. I had imagined this restriction was solely due to the zBoost device needing a tower to talk to (it cannot bridge to another backhaul) -- but in fact it may also be due to zBoost's inability to simulate the idle signaling between the handset and the tower. That is, you need a tower to make or get a call, but the zBoost can boost the data in the call stream.

So what does this all mean?

Well basically that if your RF visibility to a tower is marginal, as mine is, zBoost may still be able to help. But you don't want to rely on this to reach 911 or make any other kind of need it right now phone call, as it might take you a few minutes of moving around or monkeying with the phone to get it to realize there's any service.

Likewise, if you absolutely positively cannot miss an incoming call, this may not be the solution for you, although, interestingly, incoming signaling (calls and SMS) seems to be stronger/prioritized traffic from the tower than idle updates, and so gets to the handset more frequently, without any kind of booster present.

Extending a Cell Signal With zBoost

Although I'm curious about the AIRAVE, I'm not on Sprint and not convinced it's worth switching just for the AIRAVE capability.

But I do have a signal problem at my house, and I'm currently testing out the zBoost Wi-Ex signal booster to see how much of a dent it can make.

Unlike AIRAVE, which creates a local CDMA network and bridges it to another backhaul, the Wi-Ex is an RF repeater/amplifier. So you need to feed it a signal -- from somewhere nearby that has a signal -- and it extends the signal via a new base station and antenna.

So far I'm inconclusive on the quantitative results. Certainly, in my house, the coverage area it creates is closer to 600 square feet than the 2500 square feet advertised. But as with any RF setup, there are so many variables that this doesn't prove a heck of a lot.

I can report positive results on a qualitative measure.

Normally, the signal is so weak inside my house that, without this unit, I can receive a call signal (e.g., ring or text message) but as soon as I press "talk" it drops. 100% of the time. Also, my Blackjack had never successfully retrieved a web page from inside the house. With the zBoost unit, there is  qualitative difference: The data connection can retrieve web pages -- sometimes slower, sometimes faster, but pretty much successfully. And if I receive a call, I can answer without the call dropping instantly. Again, depending on various things the call quality may be better or worse -- but there is always a call there, struggling to get through. Which despite being reminiscent of 1995 is a major improvement.

What I'm wondering is ... if, as zBoost claims, the device is FCC legit and is designed not to create trouble for the existing cell network, why don't the cell carriers themselves sell this device? It seems like it could help them extend their reach geographically and satisfy a few more customers.

And before you suggest that they don't offer it because doing so would be tantamount to admitting their existing network footprint isn't solid, note that both T-Mobile and Sprint are already selling personal femtocells and rumors are that AT&T isn't far behind. And anyway, spotty coverage inside buildings has never been any kind of secret.

Airave and Network Sniffing for Fun and Profit

Sprint's AIRAVE BYOB (bring-your-own-backhaul) femtocell went on sale nationwide this week. Reviews seem mildly positive; it kind of costs a bunch considering you're subsidizing Sprint's infrastructure, but it's marketed toward people who have little other choice.

I don't have one (I'm not on Sprint at the moment). But if I did, the second thing I'd do with it is to start sniffing the traffic it sends back up the wire.

But all that data would be encrypted, right? Well, maybe ... and maybe not. Since Excel files seem to be an enterprise data store of choice these days for companies handling sensitive personal information, and since telcos are not the science-fair winners of the class but more like that kid in the back that just giggles all day keeps getting his lollipop stuck in his own hair, it wouldn't surprise me if they think ADPCM is encryption.

Even if some or all of the call content is encrypted, though, one could probably learn a lot about the signaling layer of the system -- i.e., how the network identifies and talks to the phones to indicate presence or session initiation.

Why would this be useful?

Well, for one thing, it would be interesting to use the AIRAVE as a presence detection mechanism. Once I can determine that the base station has recognized a known cell phone ID, I can automate all sorts of things that are supposed to happen when I'm nearby.

Applications include home automation (open locks, turn off the alarm); media (access and/or license to all of the media I own "appears" on any connected device when I'm nearby with my cell phone, and goes away when I leave); or for commerce: my hotel reservation, preferences at a restaurant, or online search history for a retailer can cue up automagically as I enter range.

iPhone Brings New Attention to AT&T's Existing 3G Problem

The wave has been building for a few days now, with consumers, Apple, and AT&T sparring over the problems with the iPhone 3G staying connected (and on 3G).

Today seems to be a local maximum and the mainstream media are starting to look.

If you read this blog regularly, you're probably expecting me to blame Apple for the problem, then blame Apple again for denying there's a problem, then blame Apple fanboys for putting up with it all for so long then suddenly acting betrayed.

Surprise!

As much as that might be a valid argument -- especially the part about Apple denying there's a problem -- this one is really not their fault.

It's kind of AT&T's fault -- and kind of GSM's fault -- and kind of just mediocre engineering.

A while back, I wrote about similar experiences with my Samsung Blackjack on AT&T. I've also seen the same thing with the AT&T 8525 (Cingular 8525 / HTC TyTn), as this was one of the first multi-protocol, multi-band 3G devices on that network.

Most people don't have any idea what this is all about, since their devices cannot experience this specific sort of problem because they don't support 3G, and so never have to resolve between 3G, EDGE, GPRS, etc.

In this case, AT&T argues that one suspect, the Infineon chipset, is not to blame because it's the same one in Samsung devices, with which they have had little problem. I don't think that's their strongest argument: others appear to be having as much trouble as I do with the Blackjack/3G. We just never made as much noise as the iPhone folks.

Perhaps a better argument would be that it affects all the EDGE/UMTS/HSDPA devices on the network and then maybe blame GSM for having such a funky data transport technology roadmap over the last 10 years.

I'm not saying AT&T could easily do better -- maybe they need more capacity and a tune-up of switching algorithms. A CNET article points to GSM carrier T-Mobile Netherlands having the same problem. And even though CDMA is worlds better as a technology, it's nice to have a little competition out there: two CDMA carriers for the U.S. out of four majors is enough.

So what does all this mean?

First, I'll tip my hat for once to the iPhonosphere and the obsessive media that love them: this is a real issue and we all know it takes a lot of volume to be heard talking to a telco.

Second, even Steve Jobs' strong-arming of the carriers worldwide (and good for him on that one!) doesn't mean everything is really under his control. According to this Sydney Morning Herald story, Apple didn't provide any test units to some carriers until the day before the product release, hoping it would all "just work."

To paraphrase someone I used to work with, in technology "hope is not a strategy."

iPhone App Store: Let's Hope It's Not All Fun and Games

The iPhone phenomenon seems to be a kind of Rorschach test, where you can find whatever you're looking for ...

There are all sorts of posts on data from the App store, looking at, for example, pricepoints in the app catalog, or the kinds of apps available.

These data are far from perfect (though worth a look), and in any case I hope that VentureBeat's post on the prevalence of Game and Entertainment apps turns out to be wrong.

Why? Mobile apps and mobile net usage have been waiting to "break out" in the U.S. for nearly 10 years. It's tempting to agree with the sentiment that mobile net use is reaching critical mass thanks to iPhone, but everyone in the industry has made that mistake many times before.

Successful off-deck software on phones in the U.S. has been more or less limited to games. So when I read the headline "Fun! Nearly half of all the iPhone App Store apps are games or entertainment," all I could think was "let's hope that it doesn't stay that way!"

I have no problem with Super Monkey Ball per se. It's just that if all the top app activity is in games and entertainment, then the mass psychology around the iPhone / App Store ecosystem is in danger of slipping irretrievably in the direction of "diversion" and not the enormous opportunity it really is.

Before you say I should just chill out about the Monkey Ball, consider:

Blackberry, because of its email device pedigree, was pigeonholed as a "corporate email/organizer device" years ago, even though it could do many other things. Despite RIM's attempt to sex up the brand, boost the hardware, cut prices and improve the design, it looks now like the window is closing for RIM to make any big gains. The enormous deployed base of Blackberries never translated into a general platform for mobile net-based computing.

At the moment, all of the top 10 -- and 18 of the top 20 -- paid App Store apps (over the last 24 hours) are Game/Entertainment apps. So right now, when the frenzy is at a peak, with mass media coverage of sold-out stores and consumers showing acquaintances their hot new gadget, the eyeballs are on the Super Monkey Balls.

To a lot of people, who have never seen a 3rd-party app on a phone, and who don't totally get what this is all about, the demonstration is going to look more like a Nintendo DS than a handheld computer.

Which raises a possibility: perhaps Apple was wise to restrict iPhone 1.0 to Safari-based apps, thus forcing consumers to view the device as a mini-web-tablet, rather than as a portable entertainment device.

I Say "Ôpen" - You Say "Õpen": It's Not iPhone vs. Android, It's Software vs. Telcos

I couldn't find the first article I had read spreading the Android vs. iPhone competition meme. No matter, it has taken root and grown like ivy. iPhone doesn't compete with feature phones or smartphones, but with Android, yada yada. Where's Microsoft and RIM, yada yada. iPhone is closed, Android is open...

Hold that last part just a sec.

It is true that by the standards of the software world, iPhone is less "open" than Android -- Android will run on lots of hardware, it is open to programming at more layers of the stack, doesn't involve an App Store or a pseudo-proprietary language. iPhone is more constrained.

It's shaping up to be an epic battle if you accept that framing of the story... But:

By the standards of the wireless telco world, both iPhone and Android are "open" (as are Symbian and Windows Mobile) because they let you choose what you want to run, and by exposing services like GPS location and push messaging to ISVs, they allow a freeform relationship between the device owner and the software vendors offering real, fast-paced innovation. Such a relationship is a huge change from tradition, where the telco mediates the relationship to the detriment of everyone involved.

Never mind if the data access costs a bit more than some folks might like (Gizmodo shows that there isn't really any change here from existing smartphone plans). The carrier has to make money somehow, and building wireless infrastructure and selling access to it is what they're good at. Controlling the user experience is not what they're good at (one reason they rank slightly below used car salesmen and vampires in terms of customer satisfaction).

Looked at this way, iPhone and Android have a whole lot in common: they're trying to push the evolution of consumer use of mobile devices while trying to wrest control of the narrative from telcos who have stifled the industry for almost a decade.

The hype and success of iPhone and Android is a boon for consumers and for the entire industry, a chance for America to move from a cellular Minitel world to an Internet world.

In Blue Trunks, Skyfire and ISPs; In Red Trunks, Multi-Core CPUs, GPUs, Smartphones, iPhone and Laptops

Skyfire is a mobile browser that has been exhibited at DEMO and has just closed a $13 million B-series funding round (they had received $4.8 million total prior funding). The elevator pitch is that Skyfire brings any web content to the mobile phone, including Flash applications, YouTube videos, Ajax, etc.

I've been trying the Skyfire beta, and I have to say that it's a neat piece of engineering, even if it's just a stripped down VNC-style screen/audio scraping client for a server-side browser session.

But I'm stunned that it has received this level of venture backing.

My surprise isn't because the software is buggy, slow, and has a bad interface on my Samsung Blackjack. Since I'm running a beta in the 0.6 or 0.7 version range, I feel I should be charitable and I'll pretend that all the bugs will be fixed by 1.0, the interface will be great, and it'll run 10x as fast as it does today.

Instead, my surprise is because Skyfire is really about a great periodic function known as "thin client, no, fat client, no, thin client, no, fat client ..." and Skyfire is the epitome of the thin-client position.

Instead of running a browser (which ironically was once considered the thin client, but is now just the universal fat client, consuming hundreds of MB of memory on a desktop to run several Flash or Ajax apps) on a small device, they punted. They'd run the browser in a data center with memory, CPU, and bandwidth, and hand the phone a 2008 equivalent of a green-screen terminal.

This is a losing proposition. For a long time now, all signs have pointed to the fact that fat clients win. And not just because they happen to offer a better user experience (thin-client proponents insist that will change 'someday' although I doubt it).

The economics and technology lean toward the fat client: Although bandwidth has gotten cheaper on an absolute dollars-per-megabit basis,

• Bandwidth has gotten more expensive relative to the speed of "local" hardware buses: USB 2.0, eSATA, PCI-X, 1333MHz memory, gigabit Ethernet etc.
• Bandwidth has gotten more expensive relative to the cost of local computation: a midgrade Intel proc costs the equivalent of a few months of home DSL or cable ISP service, and this equivalent has been stable for a number of years ... and the computational power of that midgrade CPU has gone up severalfold, while the DSL/cable bandwidth has stagnated ... and now is threatened by both metered-pricing and traffic-shaping schemes. On the GPU side, the differential has changed by orders of magnitude to the advantage of the fat client.
• A given "bandwidth experience" has gotten more expensive as users expect to be connected in multiple contexts: To have the same "experience" I have to buy the same bandwidth several times, once for when I'm home, again for when I'm on my cell phone, again when I need to use WiFi somewhere, and maybe a fourth time for a 3G laptop card.
• Cheap powerful computation has innovators, while bandwidth has innovation obstructers.

Sure, raw dollars-per-CPU-cycle and per-kWh can be optimized in a data center somewhere.

But as long as the cost to connect me and that computation dwarfs the inefficiencies of just carrying the computer with me, Skyfire and its investors have bet on the wrong horse.

Microsoft Should Trumpet, not Downplay, iPhone's Real Accomplishment (Hint: It's not about Sales Volume)

In this article, Philip Elmer-DeWitt deconstructs a Microsoft partner mass email to discuss how a heap of chest thumping is presumably hiding real insecurities about how the Windows Mobile ecosystem stacks up to that of the iPhone.

Coming before the new iPhone launch, I agree this is not a coincidence. And although I've penned defenses of Microsoft in this blog, this post isn't one them. Instead of chest thumping, Microsoft should be talking to its partners about what Apple has accomplished with the iPhone that Microsoft has not in the 6-odd years since the first Windows Mobile phone shipped... and how that accomplishment has created new opportunities and liberated new value for the entire wireless space including the WinMo world.

In a nutshell, one of the enduring problems with wireless is that no matter how good the phones got (first WAP, then Java apps -- with networking, then color and multimedia and .Net and push data and QWERTY keyboards etc.), U.S. customers just never seemed to get that this was a real computing device, that would powerfully complement their PC(s) and could be just as general in use.

No matter how much analysis showed that the phones people already had could save weeks out of their lives through increased convenience and productivity (with the right software), almost no one used productivity apps, or mobile websites, on their phone. Some conceptual chasm just stopped people in the U.S.

So Apple comes along with the iPhone. And feature-for-feature, the original iPhone OS (not the OSX core, but as it was exposed developers/users) couldn't hope to keep up with Windows Mobile 2003, let alone '07 (WinMo 6.0).

But Apple was hunting different game. By combining a beautiful interface, ridiculously fast processor (to the point that battery life suffered), and an all-in-one experience featuring massive "On Ramp" signage to apps and the web, Apple got people to understand the phone was a computer that normally, natively runs apps and accesses the network, something no one else had accomplished on a mass scale in America.

I've written before about stuff Apple does poorly. This iPhone-as-computer play isn't one of those things. It was a big gamble, but arguably Apple has pulled off another early-Macintosh-type accomplishment in terms of changing how the public understands what a device can/should do.

And, as with the Macintosh, there is no reason that this "enlightenment" should only put dollars on Apple's bottom line. It boosts Windows Mobile, Symbian, Blackberry, Palm ... by focusing free mindshare on the phone as computer.

Now the other players need to follow through. Microsoft and RIM have the lead in the U.S. -- the first thing they ought to do is stop everything and get a browser on their phones that doesn't totally stink (that's the sanitized version of how both those guys' browsers deal with the modern web).

I won't detail requirements; I think Safari on the iPhone is a clear enough target. And while the wide variety of OEM hardware that runs Windows Mobile won't all have the CPU muscle for a Safari, Microsoft should make a credible effort to replace notepad, er, I mean Pocket IE. Meanwhile, why not send out a partner mass email confessing that PIE alone is costing everyone in the WinMo value chain bigtime.

If I were Ballmer, I'd dig up half a dozen hackers from inside or outside who have worked on the Mozilla codebase. I'd get them porting whatever they could to WinMo, and I'd have an internal team building a new Pocket IE product as well. At the end of Q3 '08, whichever browser works better on the most Windows Mobile devices, becomes part of WinMo, the other guys get a mediocre line for their resume (unshipped product), a vacation, and a reassignment to the next Microsoft Bob.

Augmented Reality is Here, You Just Can't See It

Augmented reality is here now, and is going to get bigger fast. In fact, it's going to be a killer app for the semantic web.

Where did I come up with that?

Well, as far as not seeing it ... that's because it doesn't look like the picture you have in your head. You're thinking of stuff floating in midair like in Minority Report or at least a heads-up display with goggles or a sceen that overlays data onto video.

Those may be nice implementations. But the core utility of augmented reality is getting information on stuff you're near (where near can be physical or by mental association) and having it delivered to you in an actionable "heads-up way" even if it's not on a HUD.

In the information sense, AR is already popular. Joe calls Fred on his cell phone: "I'm trying to find a hardware store down here near 20th, can you hop on Google maps and find it?" Fred looks it up, maybe hits Street Views, done. Later he calls Fred again from a party: "That girl is here -- the one I met at your office party, used to work with you... what is her name? She's looking great. What is her whole deal again?" That's augmented reality by cellphone and human reverse TTY, call it v 0.5.

Then there's v 0.6, which is Google Local for Mobile/iPhone, Windows Live Mobile, or the like. GLM offers "My Location"-biased search results, while WLM has solid speech recognition (you can just tell it where you are or what you want). These mobile search products are great, except that they are relatively active, not passive -- you need to tell them what you're interested in, they doesn't already know. And they only knows a little bit about places and a little more about businesses.

Despite the limitations, these two methods are real examples of AR in use today, even if people don't call it that.

I assert that AR is a killer semantic web app because it's the semantic tools that let the machine filter the Internet down to what's relevant in your (metaphorical) field of view, when you're out in the real world.

Googling for answers in many real-world situations is drinking from a firehose, and you need to go all the way into the cyber world (iPhone, laptop, etc.) and invest effort to get what you want. That's not AR, it's just context switching and portable cyberspace.

AR is a system that can matrix your interests, contacts, places, and needs against all the current information germane to where you are or what you're doing ... and then pick out just the high level parts you want, with a mechanism to drill down by concept. Doing that by brute-force search, or even collaborative methods (think geotags), won't get you far enough. You need a true semantic layer to front-load the work and make this real-time.

On the other side, once you have a workable if basic semantic layer, then AR becomes a very basic incredibly useful flavor of personal, semantic search.

Sprint Keeps Fighting the Good Fight with 'Titan' Mobile Platform

Sprint has long been the most developer-friendly of the major carriers, and they're raising the Java bar with their new Titan platform.

Titan is a significant improvement over J2ME, and Sprint is doing the smart thing by making sure all Titan-capable devices run the same implementation (something Sprint actually started doing a few years back with their J2ME VM, in an attempt to ameliorate the write-once debug-everywhere problem).

But sadly, Sprint's leap forward (and Sun's, if they succeed in getting their SavaJe-derivative JavaFX mobile platform shipped) is just more trouble for the mobile application industry: it's yet another incompatible platform that must be supported, but which doesn't replace any existing platform.

No one wants to build or fund a company (or application project) that can only reach a subset of Sprint subscribers (those with the Titan handsets). It's a non-starter. While the iPhone has enough sex appeal to drum up an entire investment fund just for its own apps, Titan has no hope of accomplishing the same thing.

So a "great new mobile app" can only choose to support the legacy platforms and ignore Titan, or support the legacy platforms and also support Titan. Anyone else see the problem here?

Whee! AOL Leaps Into the Whirling Saw Blades

You know that cliché about horror movies where the ingénue ends up off by herself in creepy surroundings, and the audience is saying "What are you thinking? Don't go in there!" ?

Well, I'd like to start a MST3K takeoff where the "film" is a tech show off of G4TV or a clip reel from the vlogosphere, and we have, say, a VC, a computer scientist, Ted(!), and a couple o' engineers who have done their time at Initech in the audience.

They could all yell "sure, why not go in there... looks like fun" when someone (like AOL this week) does something colossally foolish, like try and build yet another abstraction platform so everyone can write little apps that run on every cellphone, everywhere, like magic.

AOL says:

"The new open platform will help stimulate innovation by providing developers with ready access to the tools and source code they need to build and distribute applications across all major mobile device platforms and operating systems including BREW, Java, Linux, RIM, Symbian, and Windows Mobile."

Anyone who's ever done anything with cross-platform mobile knows that this is a really hard problem, and not the software kind (where solid R&D might yield results), but the business/social kind, where even the resources of megacorp like AOL are a drop in the ocean.

That's ok, because they have a plan for exactly how it's gonna work. If you're playing along at home, stop reading. Close your eyes and guess the innovative architecture for pulling this rabbit out of the hat. Ok, now you can look:

"The platform will consist of three components:

• an XML-based, next-generation markup language;
• an ultra-lightweight mobile device client;
• and an application server."

I think the secret sauce must be the next generation markup language. See, the next generation markup language will become sentient, take what you write, process it into extraordinarily cogent Powerpoint, email it to all the VPs of all the mobile carriers, device manufacturers, and mobile OS vendors in the world, and then wait on a queue until they all agree to change their businesses so your stuff will work.

I've written lots of times before about the mobile app ecosystem and why, for now anyway, this kind of idea is just a complete non-starter. At least startups fail fast, since they have vaguely limited resources. Then you have players like Yahoo! that find themselves in a deep hole, and say "hmm... this is so big and so deep, we can roll an excavator down here and start the real digging!" They do things like deploy an implementation of J2ME in .net bytecode, so that people can run a mediocre (I'm being polite here, guys) MIDP app on their brand new Blackjack or HTC Touch.

In my new MST3K show, I'll keep the video clips short, so we can watch, laugh, and get on with our lives.

Using Google 'My Location' to Troubleshoot AT&T's Broken Network

The AT&T Wireless coverage in the San Francisco area is poor. It's not that the "more bars" commercials or the beautiful coverage map aren't technically accurate -- pushing enough buttons on a handset sooner or later results in bars on the display. Having calls go through and not get dropped, or having the data service behave, is another story entirely.

But this post isn't a rant about AT&T. None of the wireless carriers are perfect, and making changes in an asset-and-operations-intensive business is hard to do. (Think about all the legacy airlines biting the dust -- there are a lot of parallels in terms of the economics.)

This post is about looking at Google mobile maps' "my location" feature, which shows the location of your current cell tower, to take a few guesses at what might be going on.

The first thing I noticed when playing with "my location" is that, on freeways, there seems to be  consistent and stable handoff between towers. Not every spot on the freeway can see a tower, which might explain the fact that within 5 miles of SF there are major freeways with dark spots, where calls predictably drop. But in the covered areas, all is orderly and the service (both voice and HSDPA) is good.

Then the trouble begins: in some suburban and downtown (SF financial district) areas, it seemed as though the phone flits between towers willy-nilly, even if I'm standing still. The results are predictable: service is mediocre, and calls can drop even in downtown. The data service becomes intermittent deep the "3G coverage area" as the phone becomes confused whether 3G is available, whether to fallback to EDGE, or even GPRS. By the time the phone has done the appropriate renegotiation, it gets new information and changes its mind.

Cell phone networks are famous for sporting sophisticated hysteresis mechanisms to manage tower handoffs. Too much handoff, and the switching overhead and side effects dominate... too little handoff and, well, you drop calls. When a handset isn't moving, there is little reason (aside from site congestion) to do a handoff. But how do you know the handset isn't moving? It's a Catch-22, because without external input, the network can only guess by measuring changes in reception from nearby towers. If reception fluctuates, the client and network need to figure out if the phone is really moving, which way, and how fast.

The result is so bad in some cases, that it's almost worth having a button marked "I'm in my office" or "I'm at home" so that the user can explicitly tell the network what's happening. At my house, I'm hopping between three towers (one on the other side of a small mountain, with enough S/N to grab my phone, but not enough to even initiate a call) with the result that the phone is more or less a brick. There's no consistent data or voice service (20 minutes from downtown SF!), so the only possible change is "better."

Here's the interesting part: a lot of the AT&T network problems don't seem to occur on Sprint or Verizon (I've been on all the networks, and was an "early adopter" of digital in the U.S. back when Sprint didn't have any coverage at all in large places like, ah, Chicago.) I do not believe the difference is because Sprint or Verizon have more towers, or superior engineers. I have a feeling this is due to (1) differences between GSM and CDMA (CDMA seems to be technically superior, but business factors make GSM dominant) and (2) the fact that AT&T is a historical rollup of lots of other networks (e.g., a former TDMA or AMPS tower setup may or may not be the ideal place for a GSM tower and I doubt they were all relocated) and supports too many disparate protocols (GPRS, EDGE, HSDPA, UMTS).

Every time the phone changes its mind between HSDPA, EDGE and GPRS, it seems to have to renegotiate its presence on the network. Perhaps there's a software fault in there too, because once the phone starts changing its mind, your network connectivity is shot. Sometimes until you reboot the phone. Whereas with Sprint and Verizon, it was EV-DO all the way. Some mechanism ensured the phone never even tried to fallback, and the result was an overall smoother ride.

I actually use the Google maps data sometimes to figure out whether I'll have coverage, or whether I need to reboot my phone. Probably not what was intended, but a lot more useful than the little bars.

Blackjack / WinMo 6 Upgrade: More Baby Steps Toward Smartphone-as-Computer

I upgraded my Samsung Blackjack to Windows Mobile 6 via the new official ROM, and the upgrade pointed out a few things indicative of where the mobile industry is going.

I was actually surprised that Samsung released the upgrade -- it had been promised for the better part of a year without showing up -- rather than just force customers to buy the new Blackjack II. Eventually I realized why they had gone through with it, and why doing a full-version upgrade (not an update) of the OS on your smartphone will become commonplace: This wasn't done for me. It was done for enterprise customers who bought (or committed to buy, or were thinking of buying) hundreds or thousands of the devices.

Consumers -- especially the kind who buy smartphones -- are interested in getting a new phone every year or two. The whole free-with-contract-extension system helps that keep that flowing.

Businesses, however, buy their handsets differently (often via a more complex deal) and account for the costs of maintaining a "fleet" of mobile devices (management, email, VPN support, etc.) differently as well. For a business, cycling the devices every year or two could well be prohibitive because of the overhead, not just the equipment cost itself.

I've never been tasked with executing a smartphone rollout for a large business. But if I were, I would probably want to create a system where the average device had a lifespan from 2 to 4 years: 2 years for the high-level execs and the techies who need more power, up to 4 years for employees who travel but are not particularly sophisticated or needy when it comes to mobile email. Beyond 4 years or so, the hardware gets so outdated it's not worth the legacy hassle; it's time to buy something new.

So a regimen of solid, easy-to-install full-version OS upgrades becomes a sine qua non for device makers (Samsung) and software companies (Microsoft) who want to sell into the 3-4 year lifespan device market. RIM figured this out a long time ago, and have pushed the envelope when it comes to keeping old models (e.g., Blackberry 7250) alive for years, offering not just OS-level upgrades, but software radio protocol upgrades: an early-model 1xRTT 7250 can become a 3G EV-DO rocket with just a firmware update.

Windows Update ... on Mobile 6

Now, with Windows Mobile 6, Microsoft can also deploy updates to our phones via Windows Update. So they can be more proactive than the hardware maker or the carrier when they need to fix a serious bug or security hole, or release a new feature.

Although other devices have provided updates before, the Windows Mobile Update feature is breaking new ground because the OS runs on so many devices made by so many companies ... and on nearly every carrier on earth. The updates had better not brick too many phones; on the other hand this could be a strategic advantage in the smartphone wars.

Other Stuff

There's lots more to say about WinMo 6 and device evolution ... from Internet Sharing to more Bluetooth support to the GPS "intermediate driver" ... and those were covered well when the OS was initially release.