Mike Rowehl: This is Mobility

The whole mobile world is abuzz today about the release of the iPhone. George is standing in line like a good boy and waiting for one, which is where I should be too. But we had a bunch of AdMobby stuff and we couldn’t empty out the entire office no matter how cool the thing might be. So instead, we’ve added info about the iPhone into our device detection at AdMob so that you can target Apple as a device manufacturer. Just our way of saying “Welcome to the mobile internet Apple, very happy to have you here.”

I just recently picked up a copy of the US release of the Opera browser for the Nintendo DS for “testing purposes”. The testing has been going well!

I know what you’re all thinking.. “But Miker, what does it send?” Here’s your header pr0n you sickos:

GET /blog/ HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Nitro) Opera 8.50 [en]
Host: www.madgat.com:9090
Accept: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Connection: Keep-Alive

And the other major question I could see folks having, how is the Javascript and DOM support? Well the few little prototype.js scripts that I had hanging around from adventures with the Nokia OS browser would seem to indicate that there’s a lot missing. I don’t see the bound AJAX requests making it up to my server at all. There’s something going wrong enough in there that it looks like the request just doesn’t even get generated. I haven’t yet tried hand rolling the request without trying to use prototype though, so the stuff might be there and just not enough like normal Opera to work out of the box with the most basic of the AJAX libs. On the other hand, it does seem that innerHTML() is supported, I was able to rewrite divs and have that reflected in the page no problem.

Mobile web browser company DVC Labs has raised a round of funding. While it’s certainly nice to see something that could kick off innovation in the mobile browser area, there are a lot of red flags in there for me. For instance the press release doesn’t really say anything besides “we’ve got patents, and not we gots money too sucka!” I’m not really sure that anything like a patent pending technology is going to deliver what we need to get this whole mobile web thingy kicked off.

Take the mobile AJAX angle just to use an example. A good 80% of the problems that are out there on both sides of that debate have nothing to do with anything that should ever be patentable. The problems are that standards are sparsely supported, when they are supported the implementations tend not be be completely conformant, and the environment that these solutions are going into tend not to be built around the same set of standards the applications are delivered via. Sure, there are some bits of magic that could go in there. There’s room to fix up battery life via compressed or otherwise optimized network interaction, ditto for response time. One point out of dozens however, doesn’t even register on the Miker overall response chart.

In general the problems on the mobile web right now are around a lack of consistent application infrastructure fabric to build from. So cool, lets get some better browsers out there, but please leave the “proprietary patented world class technology” out of the mix for a while and build in some “100% open standards conforming” bits instead. Then jam in the patented bits to make your open standards based solution the fastest/coolest/best/sexiest kid on the block. Just my two cents from the active mobile developer angle.

My-Symbian has updated their E90 review based on a production unit and confirmed my worst fears:

The E90 is a quad-band GSM (850/900/1800/1900 MHz) and WCDMA 2100 MHz device. It remains unknown if a separate American version supporting American UMTS bands will be available at a later date… For now, the E90-1 model only supports 2100 MHz frequency.

Why oh why do you tempt me so Nokia? You keep saying you’re serious about the American market, but you make this American feel like a sucker for loving your phones. Please, stop the hate, and give me an E90 with US frequencies. I’m going to go sob in the corner while waiting, k?

Russ pointed me at the Mini Friday site, probably to talk about the design of the site itself. But of course I immediately got distracted by the project itself. It works very well on the E61, w00t!! The interface is really pretty simple and easy to use. And Russ and I manged to find each other pretty quick and have a conversation.

The project is apparently an experiment by the folks who do Habbo hotel. It mixes an interesting amount of presence and chat. When you’re close to someone in one of the rooms you can hear what they’re saying, so the connections are different than in an any-any room like most of the existing chat services. And you have control over setting up your avatar, which seems to always evolve into an interesting sidechannel for conversations and status. If you see me on grab me, I’m using the nick ‘Miker’.

I’ve been told that we’ve won the Innovative Business Model Award at the Meffys this year. Which I find somewhat amusing, cause I keep having these flashbacks to 2000 when I was working at Goto.com on exactly the same business model applied online instead of in mobile. But I suppose applying an idea in a new area is a kind of innovation.

Still, it’s true, that frequently when we talk to folks from the mobile world about CPC advertising in an open market it takes them a little while to grok it. As I’ve mentioned before, folks inside mobile aren’t really looking outside to find interesting things to apply. Which makes me wonder how many other setups of the kind are out there? Where else can you just pick up a model from the online world, wander into mobile, plop yourself down and “start a revolution”?

Tom Hume has a post up about launching an application that was used in combination with a live broadcast in the US. I almost missed it, but Mario and I caught the end of the show. I didn’t have a handset that I could use with the app itself, but we did watch the other bits of the audience participation on the television and pulled up the website. I think the whole set of stuff is really interesting. I happened to have wandered across a program on G4 called Star Trek 2.0 a few months ago, and spent quite a bit of time poking at it. Since then I’ve been paying a lot of attention to audience participation of the sort, watching for what interesting stuff happens.

The Ghost Detector stuff is a fantastic example. Leave alone the question of ghosts and paranormal activity, effectively what they did during the show was build a distributed participatory sensor network spread across the whole United States. Usually when people talk about that there’s a ton of infrastructure cost involved. Setup the right environment and you have people happy to pay you to participate. Fantastic!

Some of the iPhone advertisements have been posted for all of us to drool over. Sure, eyecandy eyecandy. How does the device actually work should be the big question right? What’s the battery life like? Will the market tolerate just EDGE in such an expensive device? Will a completely touchscreen based interface work? Those should be the important questions.. but let me remind you of a crappy overpriced little gadget called the RAZR that still sells in mindboggingly huge numbers.

Fear the eyecandy. Respect the eyecandy. Understand the effects of the eyecandy. Admit it, there was some point where your heart skipped a beat and you thought “wow, now that’s awfully cool” before the more logical part of your brain convinced you it was impractical. I’m no expert in consumer behavior, so I can’t tell you which is more important - the skipped heartbeat or the logical analytical side of your brain. But I was sick for a while last week and ended up more exposed to the phenomenon of daytime television than I normally am. Maybe it’s just shellshock, but I’m pretty sure it’s not always logical practicality that drives what people do.

Om has a good writeup giving an overview of the Amp’d bankruptcy issues. Aside from the actual info about Amp’d I loved this: “Amp’d had raised $360 million in funding, but in recent days ran into strong headwinds of reality…” That’s a fantastic turn of phrase, and Google shows only three occurrences! I’m going to start the effort to get that entered into the general vernacular. Then instead of having to admit that I was just pulling shit out of my ass when I came up with projections, instead I could say my project ran into some strong reality headwinds.

As far as info out of Amp’d itself I find this very interesting:

As a result of our rapid growth, our back-end infrastructure was unable to keep up with customer demand.

I’ve been having a lot of conversations with some folks who like to say things like “carrier grade” as a way of expressing that things have to scale without significant hurdles and be monitorable so that you can identify and react to potential bottlenecks before they become issues. It’s also a euphemism for “this is going to cost you about 15 times what a sane person would expect it to.” With all the cost built into the system of building a carrier network under that justification, to hear about scaling being an issue one has to wonder just how horribly wrong things have to be going.

I was about to be a big ball ‘o negativity, but I managed to stop myself. After not being nice about the whole Foleo thing earlier, I was going to go right off ranting about the whole Mobile AJAX thing, prompted by reading over the Mobile AJAX FAQ. But then I realized that’s wrong, I shouldn’t just rant all the time. Most of the time perhaps, but not all the time. Instead, I took a deep breath, calmed down, and examined why it is exactly that the mere mention of mobile AJAX normally makes the bile rise in my throat.

I don’t want to rail at Ajit and the other folks working on the FAQ, I know they’re trying to do something positive. So instead I’m trying to find a constructive way to contribute to the conversation. Why is it that I think the discussions about mobile AJAX are just too premature? Why do I consider them ‘dangerous’ even?

Way back in the deep dark depths of time I worked on a DHTML and Javascript project in a faraway galaxy called Rochester NY. I honestly don’t remember when it was, but I have to guess probably 1997. Long enough ago that there was a version of a browser that AOL was distributing that was different enough from whatever its original form was that it was considered a distinct browser. And it was important to pay attention to cause almost everyone was still getting online via AOL disks mailed to them. Very much pre-history. I don’t remember any giant lizards roaming around, but there may have been.

What we were working on was evaluating if the company could replace it’s desktop based relatively thin client installed application with the genuine thin client of a browser plus web app. The problem being that they wanted to do some relatively complex stuff for the day. DHTML, relatively heavy javascript processing, and they wanted it to look good and feel slick. We got it put together but it was a real pain to get working. Lots and lots of trial and error debugging, posting to mailing lists and news groups to find out what other tricks people were using, doing server side adaption to work around differences across IE and Netscape, and CSS really didn’t exist at all to speak of so styling was a real pain. The browsers were slow and clunky, it was relatively easy to crash them with simple stuff, IFRAMEs were even a relatively new advance. So DHTML and Javascript to do rich internet applications just left a bad taste in my mouth.

Then a few years ago, people started talking using the browser as a Javascript based thin client again and the hairs raised on the back of my neck. Why was this a good idea now when it was so horribly painful before? What makes DHTML and Javascript workable where it hadn’t been? The answer is maturity and scope of the standards and maturity and (relative) consistency of the browsers that implement them. It’s pretty difficult these days to take out a desktop browser with crappy javascript. The standard browser will cope with tons of junk thrown at it. It might not render anything, but it also won’t normally just disappear on you. You can use CSS to do styling consistently, and when you need to work around browser quirks you can do that within the browser itself.

The whole setup has led to common libraries of javascript that developers can reuse across projects so that not everyone has to deal with all the details at every level of the implementation stack. There are even some honest to goodness debugging tools like firebug to make a developers life easier and shed some light into the dark corners. AJAX on the wired web works cause the browsers are stable and mature enough to be considered a development platform. However ten years ago that wasn’t the case. Trying to build an app inside a browser was like trying to build on quicksand. And every once in a while even the quicksand would just up and disappear on you without warning.

So what’s happening now with mobile browsers? Over the last few years we’re seeing mobile browsers in significant numbers that support XHTML instead of WML, the browsers are starting to grow Javascript support, implementations are coming out based on existing desktop versions, and the network connections are getting fast enough to make a browsing experience pleasant. But even given all that we’re just at the start though. The very very very start. We can’t even get online validators to agree what is and is not valid mobile markup. And yet we think we can leapfrog to where the web is in terms of using the browser as a base platform for richer client development? All I can see that doing is setting us up for a whole bunch of pain and then a whole bunch of disappointment again. Haven’t we done that enough?

But I don’t just want to whine, so I tried to figure out what I could do to help set the framework properly for thinking about how to get us to that point if we decide we do want to be there. The Mobile AJAX FAQ says that most existing web based frameworks are too heavy to use on a mobile device (this should be counted as a warning sign by the way), but I’ve been fooling around with using prototype.js with the Nokia Open Source browser and generally found that the stuff worked. So I decided today to really dig at it and find out if I’m just being a naysayer without justification or if I would find an environment that was as unformed as the one that existed back in the day on the web.

The first thing of note was that the common pattern in AJAX programming of shipping around fragments of HTML instead of JSON if what you want to do is just update some portion of the display causes some issues right off the bat. The problem is with the carrier gateways, who will frequently try to “correct” problems they see like missing but required doctype declarations and elements. That’s really just an annoyance however, you can just always return your snippets with a content-type of text/plain (which is really more technically valid than text/html anyway, cause it’s not an HTML document on its own). Just something to keep an eye out for if you’re playing with this stuff.

Then I managed to do what I knew it should only take a bit of poking to do, I managed to find a nice simple one-liner of Javascript that takes out the browser on my E61:

var str = ‘You survived!!’.replace( new RegExp( ‘xx([\u0001-\uFFFF]*?)xx’ ) );

That’s it, just looks like funked up Unicode handling in regular expressions. But something like that is in the prototype.js library to strip scripts out of inbound HTML fragments. I found a pretty significant bug in an existing browser implementation within about 3 hours of sitting down to try to do so, and it’s a fatal error. Imagine if what I was trying to get done was write an application and not just use an existing library to vet a browser implementation. I would probably be cursing the prototype library for being buggy, and I would be dead wrong. This isn’t a new browser, it’s a port of the existing WebKit code to the Nokia devices. That gives it a leg up in terms of maturity, but it certainly doesn’t account for everything. Here’s a link to my “crash the Nokia OS browser” page by the way if you want to try it out.

If we want all this stuff to work as a whole we really need to figure out how to make it less painful to develop the stuff. As someone who still primarily writes code for a living it still very much pains me to see the visionaries point everyone into what I know is just a meat grinder in terms of what the folks implementing these systems are going to have to deal with. I’m a tremendous fan of the mobile web, so I would love to see this stuff work. But there are a few iterations to go before we can realistically think about using something like AJAX for the average mobile web developer. In the meantime all it does is muddy the waters, causes confusion, and distracts from what the real goal should be - building killer applications that expand use of the mobile web to people who never found it attractive before.

That said, I love the idea that eventually we could end up with a rich mobile web environment that could surpass the wired web, that gives me the warm fuzzies. What do we need?

• Would someone please finish the standards and get one consistent set of documents that everyone can develop to for mobile web content? Why isn’t this done yet? The wired web is an unorganized mess, the mobile web is ground zero after a nuclear blast. And it seems to be getting worse instead of better. Just when there started to be some unity around the XHTML format itself, now we have SVGt and FlashLite and compound document formats and XML widget descriptions. Any and all of which might save the world at any given moment, and may or may not be available in the next version of any given browser, and one of which will definitely obsolete everything it is that you could possibly be doing right now - we just don’t know which one. STOP IT ALREADY! One damn format, everywhere. Get it working. Get it shipped. Get it in the hands of users. Then lets talk about how to make your location enabled Javascript based widget run both in the browser and on the home screen.
• If you want to drive faster maturity of your implementations you need to open source the whole thing and let others help you find the holes in your code. The Nokia OS browser I’ve been playing with is based on the Apple WebKit code used in the Safari browser, so this should also be a problem for Safari, right? Not as far as I can tell. There are some mentions of problems with Unicode expressions in WebKit, but that seems to be back around 2005, well before the firmware I have in this device should have gone into development. I assume this is something specific to the Nokia OS implementation.
• What’s the equivalent to CLDC for Javascript/browsers/DOM? The Java environment specification requires a certain minimum amount of memory available to a Java process so that if a developer keeps under that they know their program will run without issues. As far as I know there’s nothing of the sort for ECMAscript/Javascript, is there? On limited devices like these the minimum application environment specification issue becomes a lot more important than on the desktop.
• Lets figure out what really drove the web side to consistency and make sure we setup the same situation on the mobile end. There are some fundamentally different environment issues between the two. The internet operates in an open and end-to-end manner so that new servers and new clients can be used without having to change the network in the middle. Is that how the carriers are going to operate their networks when it comes to data services? How about the device manufacturers? What makes them install a heavier and more costly web browser when there are few rich mobile web apps and few users? Or what makes mobile web developers build rich mobile web apps when there are few devices that can access them? I think the Moto RAZR and it’s 8K page limit has proven to all that the mobile web isn’t going to roll on like a juggernaut with no steps backwards. What really locks the value chain in and makes sure that no device manufacturer would dare approach a carrier with a device that had a substandard browser? And makes the carrier care enough to validate the implementations coming in and push back when there are problems? Or what’s going to happen that makes it irrelevant if these things happen because there’s a different driver for the issue?

I spend a decent amount of time talking to independent mobile media property owners trying to evaluate their service evolution and what they can expect in the future. If we don’t get at least some of those questions answered we’re not really doing what we should be doing to grow the mobile web.