Mike Rowehl: This is Mobility

Very happy to see Mozilla talking about mobile browsing at Web 2.0 Expo. W00t! Progress is being made, makes me all tingly happy.

I was mulling some of the geo hacks for the N810 that are out there now. Maemo Mapper is a great open source mapping application, there’s a little app that geocodes photos as well. Then there’s Maemo WordPy for posting to Wordpress, and I was wondering if that allowed for geocoding posts. And I was pondering the user of the N810 as a geocontent production device. As well as wondering if the geoaware primitives we could use in mobile browsers would at all be helped by the evolving state of mobile Firefox.

All the little hacks on the N810 could really be solved more easily on the web if there were a way to hook the stuff together. What I started thinking about was hacking around with the new firefox release and see if I could get it to shove geoinfo into the outgoing headers. But then I realized most of the stuff I wanted to fool around with wouldn’t take the headers in anyway. So for now instead I made just a simple little python launcher app that pulls your current location from the GPS and launches a browser with Google Maps pointed at your current location. Very simple, but I imagine with some basic URL crafting you can use it to create geocoded Wordpress posts or geotag images uploaded to flickr. Maybe I can make it a little homescreen applet to display your location and launch one of a number of sites with your location fed in.

Thinking about the way the web facing geographic services have worked out, passing a URL with the location filled in seems to make more sense right now. There was a geo-headers ietf draft floating around at one point.. but I can’t find that as an official version. Are there services out there that use it? Or something else that’s common across services?

I was somewhat curious how the new Wordpress 2.5 admin interface would play with the browser on the N810 so I spent a little time poking around. Even though the new interface seems to be a lot more squishy than the previous version, it actually seems to work a bit smoother on the device. I like Maemo Wordpy as well, but it’s nice to be able to go in and do stuff like make sure a sudden spam surge hasn’t completely overrun my comments when I’m on the go.

While I was in a testing mood I poked around with some of the Google apps as well. The search, calendar, maps, and mail apps (as well as a few others) have bookmarks loaded into the browser by default. But I wanted to play around with the reader and the iGoogle homepage. The reader worked pretty much as I expected it to. The fact that it worked at all was great, but it was a bit slow and some screen elements overlapped each other. The kind of thing that might benefit from a bit of Greasemonkey hackery.

What I was relatively surprised by however was the iGoogle version of the homepage. All the controls worked well, even dragging around modules to change the layout. The layout is dense and efficient, I can add calendar and gmail apps in there. I added a weather app in there and then was about to pull it back out cause I already have OMWeather on the desktop of the device. But then I realized iGoogle is actually a better homescreen for the N810 than the device native applet based homescreen is.

When using the RSS reader applet on the N810 the only option is to put a blended list of every item from all feeds I’m subscribed to. No way to pick and choose and select just individual feeds or a single feed to display. The font is ridiculously large and the only options for reading are punching out to either web or RSS app, no expand in place. The same goes for the email app built into the device, just overly simplistic and at the same time fragile when compared to the other apps like Claws mail (but AFAIK Claws doesn’t have an applet to go along with it). Compare that to iGoogle configured similarly. The information density is much higher, configuration options a lot richer and more flexible, and there are just more options there for existing widgets. It’s an excellent example of rising browser capability allowing online applications to displace native apps, even when those native apps have direct operating system level support on a mobile device.

Thanks to Russell for pointing out that a new set of MMA guidelines is up for review. Apparently I’m supposed to post feedback in their public forums, but I’m getting a bit tired of having to follow discussions in other places. So I’m posting my feedback in my public forum, just like they posted their recommendation on their site. Just seems proper.

As soon as I read Russell’s post I thought “Yay! Finally some structure around an accepted practice for audience measurement on the mobile web!” Cause any effort to democratize serving ads in a medium and put everyone on equal footing just needs to set down conditions of input (media styles and formats, standardize terms and minimum specification of a buy) and expected output (what should be reported and how should it be measured?) The guidelines as they stand make a point of dealing with the media formats and sizes, not bad, I have no real comments there. However, the mobile web part says nothing at all about audience measurement. Which is kind of conspicuous cause the messaging and downloaded app sections do talk about metrics and reporting.

It’s almost like it was intentionally left out, hoping no one would notice the smoking crater? I’m looking for something along the lines of the IAB Campaign Measurement guidelines. Look at the detail in there: delivery mechanisms and which inclusion tags count as which style and dealing with caching. And most important, it doesn’t matter if it’s right or wrong in every case, just that it’s consistent. Why is there information about handset screen sizes in China, and no mention of how to measure reach on the mobile web? Bad form.

Okay, I know I said the report included sections on application download and messaging audience measurement. Technically that’s true, in that their presence in the report calls into attention their absence for the mobile web section. But these are the counting and reporting “guidelines” for mobile messaging:

Operators could use counting tools that use digital fingerprinting or similar technologies to track message
distribution among users in the network. This could enable the service provider to track the dissemination
routes, to identify social leaders, and to reward users for forwarding messages. However, all these
capabilities must comply with existing national level regulatory and legal frameworks covering privacy and
the use of personal data. In addition end users concerns and expectations will always need to be
carefully managed. Taking all steps necessary to ensure end customers fully understand any proposal to
user their data, together with providing a clear choice to opt in or out of this type of service is essential for
its long term success.

Umm. I’m not sure “The carriers might do something to help count users. And oh yea, be sure not to break the law” really counts as a guideline. That’s not helpful at all, to anyone.

Then there’s the section on mobile video, which says pretty much “we’ve got no guidelines, but here’s some info about mobile video.” What the hell? Are these guidelines for usage? Or marketing material? If you don’t have guidelines for mobile video don’t include a section on mobile video in your guidelines. It’s reminiscent of padding out a book report. Was there a minimum word count for this assignment? I actually scrolled back to the top of the document and checked the title of the report again, thinking that maybe this was really just an informational release. The mobile marketing strategic overview and not a set of guidelines. But that’s what the report says, “MMA Global Mobile Advertising Guidelines”.

So lets create a specification for them so we don’t have to go through the process again. Audience numbers must be counted using the MSISDN if available and fall back on cookie based counting in all other cases. MSISDN presence is dictated by the presence of one of the following headers in a request from a mobile terminal:

• X-MSISDN
• X-NOKIA-MSISDN
• X-UP-SUBNO
• X-WAP-MSISDN
• X-UP-CALLING-LINE-ID
• USER-IDENTITY-FORWARD-MSISDN
• X-WAP-CLIENTID

It’s relatively easy to pick out which headers to use if folks publish some info about the traffic they’re getting. Cookies must be delivered with the domain of the central advertising network if appropriate, which means image based recording even for text adverts. 1×1 gif, which admittedly carriers could block.

That’s it, that’s a spec, it’s the kind of thing I would expect the MMA to put in their “guidelines”. Furthermore, given their position as the premier global organization pulling membership from carriers, software providers, and manufacturers I would expect them to:

• quantify in what percentage of cases the guidelines are expected to yield valid numbers given global averages
• work to improve the guidelines to decrease the error rate over time
• provide recommendations and guidelines to carriers, software providers, and device manufacturers to decrease the error rate going forward

If something like that happened we might have something that could “stimulate the growth of mobile marketing and its associated technologies.” As it stands now however, I don’t really see the point. It clarifies a few points if you already have an advertising business up and running. But say you’re an independent site owner looking to sell your own inventory directly, or an open source advertising platform looking to add mobile adverting to the mix of features your package provides. Read through the guidelines with that perspective in mind and it’s obvious it doesn’t provide any of the necessary clarity at all.

I did a search this morning to see if there was anything related to the cookie issue with Openwave software. Instead I found a post from Dennis saying that it appears that Sprint has now followed Vodafone in disrupting the mobile web. Ouch. And their partner in crime? Openwave. I was hoping to find some positive reaction, instead I find a new mention of negative behavior. Damn.

Great post from the Mippin folks explaining a problem with cookies on mobile devices, in the US in particular. I’ve heard support numbers all over the place from folks. Some say cookies fail 50% of the time, others say they work in all but 5% of the cases. Apparently there’s some major issues with using a bare TLD with Openwave (either browsers, gateways, or browsers and gateways - see this Openwave FAQ for some info about how they’ve mucked up identifiers). Good info to know.

If this is a browser plus gateway issue it would be nice to see it get fixed. If this is a browser issue that can’t be fixed I think we all need to make sure to continue giving Openwave folks the evil eye when you see them (I’m assuming you all do already, just keep it up). Come on Openwave! This is your chance to prove to us all you’re not completely useless. I’ll be keeping an eye out for major network changes.

I kept seeing commercials on TV saying Vehix has a mobile version. I went and poked at it however and had some issues. First off was that my N95 brought up the full web version. I’ve seen a bunch of discussions online saying things like “if the user is on a device with a full browser or using Opera Mini of course they want the full version.” From expert users sometimes even. That’s just stupid. I’m pretty sure the problem was just that the platform Vehix used just didn’t recognize the N95 But in case someone made the explicit decision to return the full version to Webkit on the N series, you were wrong. Definitely in the state it’s in now.

One of the major problems is that there’s no actual link over to the mobile version if you end up on the desktop version by mistake. I searched around on the web and didn’t find any mention of it. So I pulled on Firefox on my desktop where I have a bunch of mobile user agents saved in modify headers. The first two user agents I tried resulted in an “unsupported browser” error page. Well, that also is just dumb when you’re dealing with mobile. Seriously, if you’re going to do things all half-assed, at least allow your users to pick the right version manually if they should happen to understand what’s going on. Throwing up an error page and suggesting a bunch of desktop browsers to be using instead, that’s just poor form.

Turns out the mobile version is at http://mobile.usablenet.com/mt/www.vehix.com/ if you want to check it out. Once you can get there it really is a pretty nice mobile site. The layout is clean, selection options were a bit funky at times but workable, and it seemed like a perfectly practical site. My car is holding its resale value very nicely, that’s always great to see. Can’t really thank Vehix for that, but it put me in a good mood at least.

After my IUI Maemo Microb hackery the other day I started pondering making the browser lie to say it was an iPhone. More cause I wanted to hack around some with extensions and Microb than because I really find myself using iPhone sites all that often (though I will say that ShifD on the iPhone is way way more pleasing than it is on any other device).

I expected it to be no problem, there’s a Modify Headers extension for Firefox, there’s documentation about how to package an extension, there’s a working set of extensions to start from. Yet still I have failed.

Microb doesn’t support XUL, so I knew I couldn’t rely on the stuff for preferences and additional windows, etc. I just created a version of the plugin that held a static Modify user-agent rule to make the browser emit the same UA as an iPhone example I pulled from my logs. I loaded the xpi into my desktop browser, and sure enough when I restarted it was telling everyone it was as iPhone. W3wt! Used the instructions from the Microb site to package the extension, but there the browser behavior didn’t change. The extension wasn’t listed. I must be doing something wrong says me, how can I test this out?

Fast forward to some time hours later and way way into the wee hours of the morning. I’ve stripped out all the chrome, rewritten the install script, repackaged the browser extra packages to make sure things weren’t funky with my build system, pored over the adblock source, merged modify headers /components directory into adblock to get it to load that way, compared the installed files to my starting files, and attempted installing the extension by hand.

I know a hell of a lot more about Mozilla extensions than I did before, but I can’t help but feel much of it was in vain. Why do all these extensions work no problem on my desktop browser but fail to load on Microb? Is there a way I can get some kind of console or debugging info out of Microb? Should I be running Microb on my desktop when debugging these things? I would love to be able to just hack out Microb extensions on a whim. The way this worked out in my head was actually that I could have a few bits of pieces of stuff I liked to use and I could hack the extensions right on the device. Totally p1mp, I might even have to get a new velvet coat to wear while I do it if I can get it working. But my experience is running very counter to my expectation so far.

Michael Mace posted a great wrapup of a few threads that have been going around with respect to native vs browser based mobile development. He does a great job of laying down a nice linear story about the evolving development environment. And of course everyone who had an interest in seeing native mobile application development continue is all up in arms about his statements. I agree, kinda, but not really completely.

Of course this isn’t a black and white question. It’s not that mobile web apps have suddenly magically hit some threshold and now native apps will never be used for anything. It’s an analog value of course. Mobile web apps are getting better, the browsers more robust, the devices more capable. What’s happening is that while you HAD to write a native or Java app in the past in order to get a passable product to market, you can do more and more just using the browser.

Same exact thing as the desktop market. Pause, take a deep breath. Yes, same exact thing as the desktop market. Sure there are differences down in the details, and that doesn’t mean that mobile apps are going to be exactly like desktop apps. The market forces in play are the same. Web apps mean easier distribution, faster release cycle, higher leverage on improving the base platform, decreased barrier to entry, etc. And a third time, same exact thing as the desktop market.

Does that mean that native application development is dead on mobiles? Well, do you use any native applications on your desktop? Most people still do, but you use them when it makes sense to have a native app instead of a web based one. The same thing should shake out in mobile. That just means that native apps should be used where having a native app delivers actual increased value. Which I’m sure is what the folks defending native apps are most afraid of, needing to actually defend their position in the face of competition. That’s going to be rough, they’re so used to having a captive audience.

The overall statement from Michael I agree with however:

If you’re a mobile developer, you should consider stopping native app development and shifting to a mobile-optimized website.

Yes, that you should do. Step back and honestly ask yourself “can I do this on the mobile web instead more easily?” The answer might be no still, but for an increasing group of people it’s going to be yes. Take into account the off-deck monetization models available with advertising (and I do hope direct monetization will enter the mix soon on a global scale) and distribution through either advertising or searches (Google is sucking up as many partners as it can get to make its service the default) and the overall environment available for direct to consumer mobile web apps is starting to look like a viable alternative even when compared to native app development coupled with carrier partnerships. Because the off-deck ecosystem benefits from more network effects than the carrier model we should see it keep rolling right along now that it’s started to tip.

Update: The conversation going on around this thread has been great, plenty of bright people with excellent points to contribute. If you’re following it make sure to also read these posts:

• Sounding The Death Knell For Native Mobile Apps
• On Mobile Applications, RIP
• Standalone Mobile Apps vs Web Apps on Mobile

I’ve been fooling around a bit with doing IUI dev on and for the N810. IUI is the javascript library behind those cool iPhone web apps. It does a menu style rendering and slides and all that. It actually works quite well on the Microb browser that ships with OS2008. Here’s one of my test pages for instance:

It renders well on the minefield browser at well, but navigation doesn’t currently work:

And kick ass, with VIM installed on the N810 hacking on the pages when disconnected even is possible:

That colorscheme is delek by the way, and I think it works great on the device.